[ECOS] Scheduler Problem

[ECOS] Scheduler Problem

[James Yates]

I have just ported eCos to my own custom SH2 platform and I am now at the point of  getting a simple app up and running. I have a bootloader running on my board which copies the executable from flash to RAM, sets the CPU VBR to the correct location and jumps to the address held in the first entry of the table.
My app starts in cyg_user_start where I can print some diagnostic out of the serial port. I am infact using the example app code from the "Embedded Software Development with eCos" book. This creates 2 threads, sets them to resume when the scheduler then exits cyq_user_start where as I understand it, the scheduler is then started. 
After a couple of seconds, a load of rubbish is printed out of the serial portand then nothing else. It would appear that the first thread is starting and something is going horribly wrong but I am not sure what.

   Has anyone had any similar problems in this area or can offer any suggestions?

Example code below:

void thread_a( cyg_addrword_t data )
{
	// Store the data value passed in for this thread.
	int msg = (int)data;

	diag_printf("Thread A Start\n" );

	while( 1 )
	{
		// Increment the thread a count.
		thread_a_count++;

		// Send out a message to the diagnostic port.
		diag_printf( "Thread A, count: %d  message: %d\n", thread_a_count, msg );

		// Delay for 1 second.
		cyg_thread_delay( 100 );

		// Signal thread B using the semaphore.
		cyg_semaphore_post( &sem_signal_thread );
	}
}

void thread_b( cyg_addrword_t data )
{
	// Store the data value passed in for this thread.
	int msg = (int)data;

	diag_printf("Thread B Start\n" );

	while( 1 )
	{
		// Signal thread B using the semaphore.
		cyg_semaphore_wait( &sem_signal_thread );

		// Send out a message to the diagnostic port.
		diag_printf( "Thread B, message: %d\n", msg );
	}
}

void cyg_user_start( void )
{
	// Initialize the count for thread a.
	thread_a_count = 0;

	// It wouldn't be much of a basic example if some
	// kind of hello message wasn't output.
	diag_printf( "Hello eCos World!!!\n" );

	// Initialize the semaphore with a count of zero,
	// prior to creating the threads.
	cyg_semaphore_init( &sem_signal_thread, 0 );

	diag_printf( "Point 2\n" );

	//
	// Create our two threads.
	//
	cyg_thread_create(
			THREAD_PRIORITY,
			thread_a,
			(cyg_addrword_t) 75,
			"Thread A",
			(void *)thread_a_stack,
			THREAD_STACK_SIZE,
		    &thread_a_hdl,
		    &thread_a_obj );

	cyg_thread_create(
			THREAD_PRIORITY,
			thread_b,
			(cyg_addrword_t) 68,
			"Thread B",
			(void *)thread_b_stack,
			THREAD_STACK_SIZE,
		    &thread_b_hdl,
		    &thread_b_obj );

	// Resume the threads so they start when the scheduler
	// begins.
 	diag_printf( "Point 3\n" );
	cyg_thread_resume( thread_a_hdl );
	cyg_thread_resume( thread_b_hdl );

 	diag_printf( "Point 4\n" );

} 

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Scheduler Problem

[Iztok Zupet]

On Monday 13 October 2003 13:20, James Yates wrote:
> I have just ported eCos to my own custom SH2 platform and I am now at the
> point of  getting a simple app up and running. I have a bootloader running
> on my board which copies the executable from flash to RAM, sets the CPU VBR
> to the correct location and jumps to the address held in the first entry of
> the table. My app starts in cyg_user_start where I can print some
> diagnostic out of the serial port. I am infact using the example app code
> from the "Embedded Software Development with eCos" book. This creates 2
> threads, sets them to resume when the scheduler then exits cyq_user_start
> where as I understand it, the scheduler is then started. After a couple of
> seconds, a load of rubbish is printed out of the serial portand then
> nothing else. It would appear that the first thread is starting and
> something is going horribly wrong but I am not sure what.
>
>    Has anyone had any similar problems in this area or can offer any
> suggestions?
>
> Example code below:
>
> void thread_a( cyg_addrword_t data )
> {
> 	// Store the data value passed in for this thread.
> 	int msg = (int)data;
>
> 	diag_printf("Thread A Start\n" );
>
> 	while( 1 )
> 	{
> 		// Increment the thread a count.
> 		thread_a_count++;
>
> 		// Send out a message to the diagnostic port.
> 		diag_printf( "Thread A, count: %d  message: %d\n", thread_a_count, msg );
>
> 		// Delay for 1 second.
> 		cyg_thread_delay( 100 );
>
> 		// Signal thread B using the semaphore.
> 		cyg_semaphore_post( &sem_signal_thread );
> 	}
> }
>
> void thread_b( cyg_addrword_t data )
> {
> 	// Store the data value passed in for this thread.
> 	int msg = (int)data;
>
> 	diag_printf("Thread B Start\n" );
>
> 	while( 1 )
> 	{
> 		// Signal thread B using the semaphore.
> 		cyg_semaphore_wait( &sem_signal_thread );
>
> 		// Send out a message to the diagnostic port.
> 		diag_printf( "Thread B, message: %d\n", msg );
> 	}
> }
>
> void cyg_user_start( void )
> {
> 	// Initialize the count for thread a.
> 	thread_a_count = 0;
>
> 	// It wouldn't be much of a basic example if some
> 	// kind of hello message wasn't output.
> 	diag_printf( "Hello eCos World!!!\n" );
>
> 	// Initialize the semaphore with a count of zero,
> 	// prior to creating the threads.
> 	cyg_semaphore_init( &sem_signal_thread, 0 );
>
> 	diag_printf( "Point 2\n" );
>
> 	//
> 	// Create our two threads.
> 	//
> 	cyg_thread_create(
> 			THREAD_PRIORITY,
> 			thread_a,
> 			(cyg_addrword_t) 75,
> 			"Thread A",
> 			(void *)thread_a_stack,
> 			THREAD_STACK_SIZE,
> 		    &thread_a_hdl,
> 		    &thread_a_obj );
>
> 	cyg_thread_create(
> 			THREAD_PRIORITY,
> 			thread_b,
> 			(cyg_addrword_t) 68,
> 			"Thread B",
> 			(void *)thread_b_stack,
> 			THREAD_STACK_SIZE,
> 		    &thread_b_hdl,
> 		    &thread_b_obj );
>
> 	// Resume the threads so they start when the scheduler
> 	// begins.
>  	diag_printf( "Point 3\n" );
> 	cyg_thread_resume( thread_a_hdl );
> 	cyg_thread_resume( thread_b_hdl );

You should start the scheduler here, otherwise it's never started:

    	Cyg_Scheduler::scheduler.start(); 	// This function never returns

>
>  	diag_printf( "Point 4\n" );
>
> }

Regards
Iztok

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Scheduler Problem

[Gary Thomas]

On Mon, 2003-10-13 at 05:26, Iztok Zupet wrote:
> On Monday 13 October 2003 13:20, James Yates wrote:
> > I have just ported eCos to my own custom SH2 platform and I am now at the
> > point of  getting a simple app up and running. I have a bootloader running

 ... snip
> 
> You should start the scheduler here, otherwise it's never started:
> 
>     	Cyg_Scheduler::scheduler.start(); 	// This function never returns

Or, since this is probably just a C program (not C++)
	cyg_scheduler_start();

Also, James - have you run any of the standard eCos test programs?
They are there to test the behaviour of a port and can tell you a
lot about what works (and what doesn't).

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Scheduler problem

[Nick Garnett]

"liu hua" <rongye_liu@hotmail.com> writes:

> In the tewothreads example program, if I don't use cyg_thread_delay()
> in the 'simple_program' thread, or if use cyg_thread_delay(0), the two
> threads cannt be scheduled normally.  The result is only one thread
> can run, and another thread is hung. thread program:
> void simple_program(cyg_addrword_t data)
> {
>   int message = (int) data;
>   int delay;
> 
>   printf("Beginning execution; thread data is %d\n", message);
> 
>   //cyg_thread_delay(200);
> 
>   for (;;) {
>     //delay = 0+ (rand() % 0);
> 
>     /* note: printf() must be protected by a
>        call to cyg_mutex_lock() */
>     cyg_mutex_lock(&cliblock); {
>       printf("Thread %d: and now a delay of %d clock ticks\n",
> 	     message, delay);
>     }
>     cyg_mutex_unlock(&cliblock);
>     cyg_thread_delay(0);
>   }
> }
> Output result:
> Thread 0: and now a delay of 0 clock ticks
> Thread 0: and now a delay of 0 clock ticks
> Thread 0: and now a delay of 0 clock ticks
> Thread 0: and now a delay of 0 clock ticks
> ...

Thread 0 is higher priority that thread 1. Without the delays, thread
0 is always runnable and will always occupy the CPU. Thread 1 will
never get to execute.

> 
> So, in my ecos application which have many thread have follow program:
> while (1)
> {
>   ...
> }

If you write all your threads to just loop like this, then only the
highest priority thread will run. Just like you discovered above.


> If must I use cyg_thread_delay(delay) in it? ie:
> while (1)
> {
>  ...
>   cyg_thread_delay(delay);
> }
> 
> If I must use cyg_thread_delay() in these threads, the performance of
> ecos will be a bad thing.


The general approach for writing multi-threaded applications is to
make threads wait for some event, do some processing, and then go back
to waiting. The event may be an interrupt, a timer, or a
synchronization action by some other thread.

-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Scheduler problem

[John Newlin]

On Apr 1, 2005 12:37 AM, liu hua <rongye_liu@hotmail.com> wrote:
> In the tewothreads example program, if I don't use cyg_thread_delay() in
> the 'simple_program' thread, or if use cyg_thread_delay(0), the two threads
> cannt be scheduled normally.  The result is only one thread can run, and
> another thread is hung.
> 
> thread program:
> void simple_program(cyg_addrword_t data)
> {
>   int message = (int) data;
>   int delay;
> 
>   printf("Beginning execution; thread data is %d\n", message);
> 
>   //cyg_thread_delay(200);
> 
>   for (;;) {
>     //delay = 0+ (rand() % 0);
> 
>     /* note: printf() must be protected by a
>        call to cyg_mutex_lock() */
>     cyg_mutex_lock(&cliblock); {
>       printf("Thread %d: and now a delay of %d clock ticks\n",
>              message, delay);
>     }
>     cyg_mutex_unlock(&cliblock);
>     cyg_thread_delay(0);
>   }
> }
> Output result:
> Thread 0: and now a delay of 0 clock ticks
> Thread 0: and now a delay of 0 clock ticks
> Thread 0: and now a delay of 0 clock ticks
> Thread 0: and now a delay of 0 clock ticks
> ...
> 
> So, in my ecos application which have many thread have follow program:
> while (1)
> {
>   ...
> }
> If must I use cyg_thread_delay(delay) in it?
> ie:
> while (1)
> {
>  ...
>   cyg_thread_delay(delay);
> }
> 
> If I must use cyg_thread_delay() in these threads, the performance of ecos
> will be a bad thing.
> 

Mutexes are typically intended to be held for a very short period of
time.  In your example the lock is held almost all of the time.  In a
typical application where you hold the lock for a very short amount of
time, the mutexes work as one might expect.

If you want to change the behavior, the place to look is in mutex.cxx.
 In the lock method, before taking the lock you could check if other
threads are currently waiting.  If they are, then enqueue your thread,
and let the one at the top of the queue run.

The beauty of ECOS, is that if you don't like how it's implemented,
you can change it.  :)

-john

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Scheduler problem

[liu hua]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 1556 bytes --]

In the tewothreads example program, if I don't use cyg_thread_delay() in 
the 'simple_program' thread, or if use cyg_thread_delay(0), the two threads 
cannt be scheduled normally.  The result is only one thread can run, and 
another thread is hung. 

thread program:
void simple_program(cyg_addrword_t data)
{
  int message = (int) data;
  int delay;

  printf("Beginning execution; thread data is %d\n", message);

  //cyg_thread_delay(200);

  for (;;) {
    //delay = 0+ (rand() % 0);

    /* note: printf() must be protected by a
       call to cyg_mutex_lock() */
    cyg_mutex_lock(&cliblock); {
      printf("Thread %d: and now a delay of %d clock ticks\n",
	     message, delay);
    }
    cyg_mutex_unlock(&cliblock);
    cyg_thread_delay(0);
  }
}
Output result:
Thread 0: and now a delay of 0 clock ticks
Thread 0: and now a delay of 0 clock ticks
Thread 0: and now a delay of 0 clock ticks
Thread 0: and now a delay of 0 clock ticks
...

So, in my ecos application which have many thread have follow program:
while (1)
{
  ...
}
If must I use cyg_thread_delay(delay) in it? 
ie:
while (1)
{
 ...
  cyg_thread_delay(delay);
}

If I must use cyg_thread_delay() in these threads, the performance of ecos 
will be a bad thing.

_________________________________________________________________
ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.com  


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] scheduler problem

[mohanlal jangir]

> Hi,
> I am working on ecos.I have got  struct with the scheduler.
> My problem is  some thing like this.
> Suppose we have 3 threads t1,t2,t3.
> t1 is having priority 2,t2 is having priority 4,t3 having priority 5.
> Now if the threads are resumed t1 gets the cpu first then t2  and last
> t3.
> so my doubt is how does the MLQ scheduler behave when the threads are
> assigned with different priorities.
The same way, you explained above. The highest priority runnable thread gets
cpu. In case of equal priorities, round robin scheduling is done if time
slicing is enabled.

> I also wanted to know how does the MLQ scheduler seperates the ready
> queue into foreground and background process  and  assigns priority to
> them.
There are no processes. eCos is not Linux.

> If any examples with explaination or is there any books or
> tutorials that clearely explains this.
See documentation in doc/html/ref/ecos-ref.html. You can find examples as
well.

Regards
Mohanlal



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] scheduler problem

[Aravind B]

Hi,
	I am working on ecos.I have got  struct with the scheduler.
	My problem is  some thing like this.
Suppose we have 3 threads t1,t2,t3.
t1 is having priority 2,t2 is having priority 4,t3 having priority 5.
Now if the threads are resumed t1 gets the cpu first then t2  and last
t3.
so my doubt is how does the MLQ scheduler behave when the threads are
assigned with different priorities.
I also wanted to know how does the MLQ scheduler seperates the ready
queue into foreground and background process  and  assigns priority to
them.If any examples with explaination or is there any books or
tutorials that clearely explains this.

thank you in advance.

##############################
Aravind B
Trainee Engineer 
CSIL.
##############################


_______________________________________________
This email with any attachments is for the exclusive use of the intended
recipient/s & may contain confidential & legally privileged information.
If you are not the intended recipient pls notify the sender immediately
& delete the email from your system. Any unauthorised use, disclosure,
printing, dissemination, forwarding or copying of this mail is strictly
prohibited and unlawful.
Visit us at : http://www.cranessoftware.com



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] scheduler problem

[Andrew Lunn]

> 	I have written a code which creates 2 threads with different
> priorities.In the higest priority i have given a while loop.So the
> control is not going to lowest priority.But the code works if threads
> with equal priority is given.
>  I wanted to know how the MLQ scheduler works if threads with different
> priorities are given.

The highest priority runnable thread is run. 

If there are multiple runnable threads at that priority and time
slicing is enabled, it will round robin between those threads of equal
priority.

Lower priority threads will never run when there is a runnable higher
priority thread.

         Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] scheduler problem

[Aravind B]

	I have written a code which creates 2 threads with different
priorities.In the higest priority i have given a while loop.So the
control is not going to lowest priority.But the code works if threads
with equal priority is given.
 I wanted to know how the MLQ scheduler works if threads with different
priorities are given.

Aravind


_______________________________________________
This email with any attachments is for the exclusive use of the intended
recipient/s & may contain confidential & legally privileged information.
If you are not the intended recipient pls notify the sender immediately
& delete the email from your system. Any unauthorised use, disclosure,
printing, dissemination, forwarding or copying of this mail is strictly
prohibited and unlawful.
Visit us at : http://www.cranessoftware.com



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] Scheduler Problem

[James Yates]

Thanks for your help. Just run the context test in the HAL which doesn't seem to run.

Thanks once again.

	James

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: 13 October 2003 13:02
To: James Yates
Cc: iz@vsr.si; ecos-discuss@sources.redhat.com
Subject: RE: [ECOS] Scheduler Problem


On Mon, 2003-10-13 at 05:55, James Yates wrote:
> Gary,
> 
>    Ho I haven't run any of the test programs. Are these built with the same memory model. Because I am using a custom bootloader due to project requirements everything has to be placed exactly right. Also I have just noticed that when corrupted output is sent to my serial port once cyg_scheduler_start() is called, pressing enter on the terminal causes another line of corrupted out to appear. I think perhaps a rom monitor stub is in the way? I tried disabling all gdb_stub related options but now get no diag output. :-(
> 

Build the tests using the same kernel (and memory model) as the 
application you are testing.  Start with the HAL & kernel tests - 
they'll tell you something about whether the basic system is working.

As for the "strange" output - it's probably a GDB string.  Can you
send it to use?  If it looks something like "$T004;...", then it is
definitely GDB telling you that the program has gone awry.   Connect
to the board using GDB and you can learn a lot more.

> I will keep at it. Thansk for your help. If you think of anything else I would be very appreciative.
> 
> 		James
> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: 13 October 2003 12:49
> To: iz@vsr.si
> Cc: James Yates; ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] Scheduler Problem
> 
> 
> On Mon, 2003-10-13 at 05:26, Iztok Zupet wrote:
> > On Monday 13 October 2003 13:20, James Yates wrote:
> > > I have just ported eCos to my own custom SH2 platform and I am now at the
> > > point of  getting a simple app up and running. I have a bootloader running
> 
>  ... snip
> > 
> > You should start the scheduler here, otherwise it's never started:
> > 
> >     	Cyg_Scheduler::scheduler.start(); 	// This function never returns
> 
> Or, since this is probably just a C program (not C++)
> 	cyg_scheduler_start();
> 
> Also, James - have you run any of the standard eCos test programs?
> They are there to test the behaviour of a port and can tell you a
> lot about what works (and what doesn't).
> 
> -- 
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] Scheduler Problem

[Gary Thomas]

On Mon, 2003-10-13 at 05:55, James Yates wrote:
> Gary,
> 
>    Ho I haven't run any of the test programs. Are these built with the same memory model. Because I am using a custom bootloader due to project requirements everything has to be placed exactly right. Also I have just noticed that when corrupted output is sent to my serial port once cyg_scheduler_start() is called, pressing enter on the terminal causes another line of corrupted out to appear. I think perhaps a rom monitor stub is in the way? I tried disabling all gdb_stub related options but now get no diag output. :-(
> 

Build the tests using the same kernel (and memory model) as the 
application you are testing.  Start with the HAL & kernel tests - 
they'll tell you something about whether the basic system is working.

As for the "strange" output - it's probably a GDB string.  Can you
send it to use?  If it looks something like "$T004;...", then it is
definitely GDB telling you that the program has gone awry.   Connect
to the board using GDB and you can learn a lot more.

> I will keep at it. Thansk for your help. If you think of anything else I would be very appreciative.
> 
> 		James
> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: 13 October 2003 12:49
> To: iz@vsr.si
> Cc: James Yates; ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] Scheduler Problem
> 
> 
> On Mon, 2003-10-13 at 05:26, Iztok Zupet wrote:
> > On Monday 13 October 2003 13:20, James Yates wrote:
> > > I have just ported eCos to my own custom SH2 platform and I am now at the
> > > point of  getting a simple app up and running. I have a bootloader running
> 
>  ... snip
> > 
> > You should start the scheduler here, otherwise it's never started:
> > 
> >     	Cyg_Scheduler::scheduler.start(); 	// This function never returns
> 
> Or, since this is probably just a C program (not C++)
> 	cyg_scheduler_start();
> 
> Also, James - have you run any of the standard eCos test programs?
> They are there to test the behaviour of a port and can tell you a
> lot about what works (and what doesn't).
> 
> -- 
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] Scheduler Problem

[James Yates]

Gary,

   Ho I haven't run any of the test programs. Are these built with the same memory model. Because I am using a custom bootloader due to project requirements everything has to be placed exactly right. Also I have just noticed that when corrupted output is sent to my serial port once cyg_scheduler_start() is called, pressing enter on the terminal causes another line of corrupted out to appear. I think perhaps a rom monitor stub is in the way? I tried disabling all gdb_stub related options but now get no diag output. :-(

I will keep at it. Thansk for your help. If you think of anything else I would be very appreciative.

		James

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: 13 October 2003 12:49
To: iz@vsr.si
Cc: James Yates; ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Scheduler Problem


On Mon, 2003-10-13 at 05:26, Iztok Zupet wrote:
> On Monday 13 October 2003 13:20, James Yates wrote:
> > I have just ported eCos to my own custom SH2 platform and I am now at the
> > point of  getting a simple app up and running. I have a bootloader running

 ... snip
> 
> You should start the scheduler here, otherwise it's never started:
> 
>     	Cyg_Scheduler::scheduler.start(); 	// This function never returns

Or, since this is probably just a C program (not C++)
	cyg_scheduler_start();

Also, James - have you run any of the standard eCos test programs?
They are there to test the behaviour of a port and can tell you a
lot about what works (and what doesn't).

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss