I am working on redesign an existing L2TP(Layer 2 tunneling protocol) code.
For L2TP , the number of tunnels we support is 96K. L2TP protocol has a keep-alive mechanism where it needs to send HELLO msges.
Say if we have 96,000 tunnels for which L2TPd needs to send HELLO msg after configured timeout value , what is the best way to implement it ?
Right now , we have a timer thread , where for every 1sec , we iterate and send HELLO msges. This design is a old design which is not scaling now.
Please suggest me a design to handle large number of timers.
There are a couple of ways to implement timers:
1) select: this system call allows you to wait on a file descriptor, and then wake up. You can wait on a file descriptor that does nothing as a timeout
2) Posix Condition Variables: similar to select, they have a time out mechanism built in.
3) If you are using UNIX, you can set a UNIX signal to wake up.
Those are basic ideas. You can see how well they scale to multiple timers; I would guess you'd have to have multiple condvars/selects for some handful of the threads.
Dependingo on the behaviour you want, you would probably want a thread for every 100 timers or so, and use one of the mechanisms above to wake up
one of the timers. You'd have a thread sitting in a loop, and keeping
track on each of the 100 timeouts, then waking up.
Once you exceed 100 timers, you would simply create a new thread and have it manage the next 100 timers and so on.
I don't know if 100 is the right granularity, but it's something you'd play with.
Hopefully that's what you are looking for.
Typically, such requirements are met with a delta-queue. When a timeout is required, get the system tick count and add the timeout interval to it. This gives the Timeout Expiry Tick Count, (TETC). Insert the socket object into a queue that is sorted by decreasing TETC and have the thread wait for the TETC of the item at the head of the queue.
Typically, with asocket timeouts, queue insertion is cheap because there are many timeouts with the same interval and so new timeout insertion will normally take place at the queue tail.
Management of the queue, (actually, since insertion into the sorted queue could take place anywhere, it's more like a list than a queue, but whatever:), is best kept to one timeout thread that is normally performing a timed wait on a condvar or semaphore for the lowest TETC. New timeout-objects can then be queued to the thread on a thread-safe concurrent queue and signaled to the timeout-handler thread by the sema/condvar.
When the timeout thread becomes ready on TETC timeout, it could call some 'OnTimeout' method of the object itself, or it might put the timed-out object onto a threadpool input queue.
Such a delta-queue is much more efficient for handling large numbers of timeouts than any polling scheme, especially for requirements with longish intervals. No polling is required, no CPU/memory bandwidth wasted on continual iterations and the typical latency is going to be a system clock-tick or two.
It is dependent on the processor/OS, kernel version, architecture.
In linux, one of the option is to use its timer functionality for multiple timers. Addition of timer can be done using add_timer in linux. You can define it using timer_list and initilialize internal values of timer using init_timer.
Followed by it register it using add_timer after filling timer_list(timeout(expire), function to execute after timeout(function), parameter to the function(data)) appropriately for respective timer. If jiffies is more than or equal to timeout(expire), then the respective timer handler(function) shall be triggered.
Some processors have provisioning for timer wheels(that consists of a number of queues that are placed equally in time in slots) which can be configured for a wide range of timers,timeouts as per the requirement.
Related
Serial port open to the public and a thread always works with the port.
One or more high priority thread are created at run-time witch without Conflict with the main thread should work with the port and destroy when completed.
how can i schedule these threads and manage access to serial port?
thanks.
In case you are creating many threads and you always want only one thread to work with the serial port (one thread at a time), you can manage it's access through the use of semaphores (so that they do not collide).
However the scheduling algorithm which you want to use purely depends on your need. When you are creating more than one thread I am sure you must be using pthread_create API which has more flexibility to set your attributes (such as priority) in it's second parameter. Please use that parameter to set you priority levels. You can schedule them by taking their priorities into consideration or you can even use a time slice technique.
When analyzing your question it looks like you are working on some development board. In case it is an RTOS code, you can try implementing the preemption mechanism along with semaphores.
We are using embedded C for the VxWorks real time operating system.
Currently, all of our UDP connections are started with TaskSpawn().
This routine creates and activates a new task with a specified
priority and options and returns a system-assigned ID.
We specify the task size, a priority, and pass in an entry point.
These are continuous connections, and thus every entry point contains an infinite loop where we delay before the next iteration.
Then I discovered period().
period spawns a task to call a function periodically.
Period sounds like what we should be using instead, but I can't find any information on when you would prefer this function over TaskSpawn. Period also doesn't allow specifying the task size or the priority, so how is it decided? Is the task size dynamic? What will the priority be?
There are also watchdogs.
Any task may create a watchdog timer and use it to run a specified
routine in the context of the system-clock ISR, after a specified
delay.
Again, this seems to be in line with the goal of processing data at a particular rate. Which do I choose when a task must continuously execute code at the same rate (i.e. in real time)?
What are the differences between these 3 methods?
Here is a little clarification:
taskSpawn(..) creates a task with which you're free to do anything with you like.
Watchdogs shall only be used to monitor time constraints. Remember that the callback of the watchdog is executed within the context of the system clock ISR which has many limitations (e.g. free stack size, never use blocking function calls in an ISR, ...). Additionally executing "a lot of code" in the system clock ISR slows down your entire system.
period(..) is intended to be a helper for the VxWorks shell and not to be used by a program.
With that being said your only option is to use taskSpawn(..) unless you're doing some very simple stuff in which case period(..) might be ok to use.
If you need to do things cyclically in a specific time frame you might look at timers or taskDelay(..) in combination with sysClkRateSet(..).
Another option is to create two tasks. One that is setting a semaphore after a specific time intervall and the other "worker" tasks waits for this semaphore to do something. With that approach you separate "timing" from "action" which proved to be benefitial according to my experience. You also might want to monitor excution time of the "worker" task by using a watchdog.
I am writing a Gif animator in C.
I have two threads running in parallel, both . The first allows the user to alter the speed of the animation. The second draws the current frame, and then calls Sleep(Constant * 100 / CurrentSpeed), where CurrentSpeed is a percentage amount, ranging from 1 to 200.
The problem is that if you quickly change the speed from 100%, to 1%, and then back to the first, the second thread will execute the following:
Sleep(Constant * 100)
This will draw frame A, wait many seconds (although the speed was changed by the user), and only then draw B and the following frames in the default speed.
It seems to me that Sleep is a poor choice of mine in this case. What can I do to solve this problem?
EDIT:
The code I currently have (Simplified):
while (1) {
InvalidateRect(Handle, &ImageRect, FALSE);
if (shouldDispose) {
break;
}
if (DelayTime)
Sleep(DelayTime * 100 / CurrentSpeed);
SelectNextImage();
}
Instead of calling Sleep() with the desired frame rate, why don't you call it with a constant interval of 1 ms, for example, and use a variable as a counter?
For example, let C be a global variable (counter) which is loaded with a number of 'ticks' of 1ms. Then, write the loop:
while(1) { //Main loop of the player thread
if (C > 0) C--;
if (C == 0) nextframe(); //if counter reaches 0, load next frame.
Sleep(1);
}
The control thread would load C with a number of 1ms ticks (i.e. frame rate), and the player thread will never be stopped beyond 1 ms. The use of 1ms as the base rate is arbitrary. Use the minimum time that allows you the maximum frame rate, in order to load CPU the less as possible.
EDIT
After some hot comments (arguing is good after all), I'd like to point out that this solution is sub-optimal, i.e., it doesn't use any OS mechanism for signaling threads or any other API for preventing the thread from wasting CPU time. The solution shown here is generic: it may be used in any system (even in embedded systems without any running OS. But above all, it is based on the original code posted by the user that asked the question: using Sleep(), how can I achieve my purpose. I give him my humble answer. Anyway, I encourage other people to write sample code using the appropriate API for achieving the same goal. With no hard feelings, special thanks to Martin James.
Find a synchro API on your OS that allows a wait with a timeout, eg. WaitForSingleObject() on Windows. If you want to change the delay, change the timeout and signal the event upon which the WFSO is waiting to make it return 'early' and restart the wait with the new timeout.
Polling with Sleep(1) loops is rarely justifiable.
Create a waitable timer. When you set the timer, you can specify a callback function that will run in the setting thread's context. This means you can do it with two threads, but it actually works just fine with only a single thread as well.
The main advantage of a waitable timer is, however, that it is more accurate and more reliable than Sleep. A timer is conceptually much different from Sleep insofar as Sleep only gives up control and the scheduler marks the thread as ready to run when the time is up and when the scheduler runs anyway. It doesn't do anything beyond that. Which means that the thread will eventually be scheduled to run again, like any other thread that is ready.
A thread that is waiting on a timer (or other waitable object) causes the scheduler to run when the timer is up and has its priority temporarily boosted. It therefore runs not only more reliably and more closely to the desired time, but also earlier than all other threads with the same base priority. Which does not give a realtime guarantee but at least gives a sort of "soft guarantee".
If you still want to use Sleep, use SleepEx instead which you can alert, either by queueing an APC, or by calling the undocumented NtAlertThread function.
In any case, Sleep is troublesome not only because of being unreliable, but also because it bases on the granularity of the system-wide timer. Which you can, of course, set to as low as 1ms (or less on some systems), but that will cause a lot of unnecessary interrupts.
Does anybody know if it is possible to make a high resolution timer in Erlang?
According to documentation all timers and timeouts are measured in milliseconds.
There is need to make a delay in microseconds. For example, instead of
timer:apply_after(MilliSec, Module, Function, Arguments).
something like
timer:apply_after(MicroSec, Module, Function, Arguments).
Indeed, all timers and timeouts primitives are in milliseconds including :
receive ... after primitive (which is what timer module eventually relies upon);
erlang:send_after/3 and erlang:start_timer/3 which rely on the same mechanism;
driver_set_timer function for linked in drivers.
Two methods could be considered to achieve a sub-millisecond timer:
use Erlang primitives to wait the truncated number of milliseconds and then adjust with a busy loop. Please note that erlang:now() is not a real time function as it is guaranteed to be monotonous (and this is quite expensive). You should use os:timestamp() instead;
write native code that spawns a thread that will send a message when the timer fires. This could easily be implemented as a NIF.
In practice,if you need a timer,you should use eralng:send_after/3 or erlang:start_timer/3,instead of timer module. The Timer module use the timer process to
implement the timer, if the application has too much timer ,it will block the timer process which will slow you application .
erlang:send_after/3 and erlang:start_timer/3 has one difference.
erlang:start_timer/3 will send the message {timeout, TimerRef, Msg} to Dest after Time milliseconds. erlang:send_after/3 will send just the Msg to Dest after Time millisecond.
The problem is when you need to cancel the timer , and the Msg has been send,if you use erlang:send_after/3,it may cause logic handle issue.
So I have an embedded Linux device that is connected to a motor controller via a serial port. I am writing an interface library which makes a lot of nice generic functions which other programs will call. One of which is a function to run the program that is currently on the controller's flash disk:
int run_motor_program(int serial_fd, char *label, timeout);
The general pseudocode for this function is:
call write(serial_fd, "start program at `label`")
perform a couple read()'s / write()'s to check whether program has started on the motor controller
do
/* some stuff */
while(program is running AND timeout hasn't exceeded)
If the timeout exceeded, kill motor and return timeout error
The timeout in the above function definition is used in case something goes wrong while running the program on the motor controller. If the motor controller gets stuck in a longer loop than expected, I need the ability to stop program.
The only ways I know for keeping track of a timeout are:
1) Calling gettimeofday() before and during the loop to see if elapsed time is > timeout value passed in
2) Calling clock_gettime() and basically doing the same as 1.
3) Using timer_create() before the loop and timer_getoverrun() in the loop to check if the time has elapsed (this seems to be the most elegant solution, but I can't seem to get timer_getoverrun() to work with SIGEV_NONE [I don't want to use signals]).
Which of these (or if anyone has any other suggestions) is the best way to handle including a timeout in a function? I really only need resolution down to the millisecond.
I tend to do option 1 myself. If subsecond granularity isn't needed, then I'll use time. Typically the work is checking for IO, so I also use a select with a timeout configured.
You could consider using one of the alarm signal mechanisms. The simplest and oldest is alarm(), which schedules a SIGALRM signal after the specified number of seconds. If you have a signal handler for SIGALRM, your process won't die but will allow you to recover from the error.
The primary limitation of alarm() is that it deals in whole seconds. There are a plethora of sub-second or fractional second alternatives. You should look at setitimer(). You might use nanosleep() but you'd probably also need to use threads since nanosleep() blocks the calling thread. That moves it up the complexity scale. There are calls like pthread_cond_timedwait() that could also be used in a threaded program.
Your prototype int run_motor_program(int serial_fd, char *label, timeout); won't compile; you need to define the type of the timeout argument. You also need to decide what your argument means - whether it is an interval or duration of time (the number of seconds to run the motor for before timing out) or whether it is the end time (the Unix time after which the program must be stopped). There are various sub-second structures that you'll have to negotiate. Your choice is likely to be affected by which system call you use for implementing the timeout.