I am planning to write some software direct to an FPGA network card, to catch incoming customised network packets.
Eventually I believe I will send the data obtained either to the kernel or to a user application. This is for a latency-critical trading research project.
What kind of nanosecond timing instruments could I use due to the accuracy required and also the fact that I am timing the duration between reception at the PCI-E network card and receivership in the kernel?
This will be on Linux, with "driver" code (I may put the user application at this level to cut latency) written in C.
On linux access to the CPU clock tick is through the tsc equivalent to the Windows QueryPerformanceCOunter
clock_gettime uses HPET if available, which is simple and as good and as reliable as you can get.
If HPET is not available, you have no reliable timer at that scale anyway, so unluckily the resolution of clock_gettime will be worse, but that's just what it is, and there's not much you can do about it.
Any other source, including tsc, is either lower resolution or unreliable or both.
In software every thing happens on multiples of system clock. I think you can use any time measurement function that returns the number of elapsed clock ticks, clock() for example should give you enough accuracy.
Related
Based on my understanding, the CPU has a "hardware timer" that fires an interrupt when its interval expires.
The kernel uses this hardware timer to implement the scheduling mechanism for the processes, so if the hardware timer fires an interrupt with the number of 123, the kernel will map this interrupt number to an interrupt handler that executes the scheduler code (which will decide which process to execute next).
I have two questions:
Can the kernel set the interval of the hardware timer, or is the interval a fixed number that can't be changed programmatically?
Does the CPU have a dedicated hardware timer for scheduling or is there many hardware timers, and the kernel can choose whichever timer it wants to use for scheduling?
Edit: The hardware architecture I am more interested in is a PC, but I would like to know if other architectures (for example: a mobile phone, a raspberry PI, etc.) works in a similar way.
Details are hardware specific (might be different with various motherboards, chipsets, processors; read about SouthBridge). Read about High Precision Event Timer (and APIC).
See also OSDEV wiki, notably Programmable Interval Timer.
(so the answer is usually yes to both questions)
From early on, IBM-compatible PCs had PITs (Programmable Interval Timers): IBM PC and IBM PC XT had the Intel 8253, the IBM PC AT introduced the Intel 8254.
From the IBM PC Technical Reference from April 1984, page 1-11:
System Timers
Three programmable timer/counters are used by the system as follows: Channel 0 is a general-purpose timer providing a constant time base for implementing a time-of-day clock, Channel 1 times and requests refresh cycles from the Direct Memory Access (DMA) channel, and Channel 2 supports the tone generation for the speaker. [...]
Channel 0 is exactly the "constant time base," the "interval" you are asking for. And, to answer your 1st question, it is changeable; it is the Programmable Interval Timer.
However, the CPU built into the original IBM PC was the Intel 8088, basically an Intel 8086 with an 8-bit data bus. Real Mode was the state of the art back then; Protected Mode was introduced some years later with the Intel 80286, so effective multitasking, let alone preemptive multitasking or multithreading, were of no concern in those days when DOS reigned the market.
Fast-forwarding to the IBM PC AT, the world was blessed with a Protected Mode-capable CPU, the Intel 80286, and the Intel 8254 was introduced, a "[...] superset of the 8253." (from the 8254 PIT datasheet). If you really want an in-depth understanding of the PITs, read the 8253/8254 datasheets linked at the bottom. It might also be worth looking at Linux. Since the latest kernels are way too complicated to really understand the particular parts in a matter of twenty minutes, I suggest you look at Linux 0.01, the very first release. _timer_interrupt in kernel/system_calls.s might be interesting and from there you can go wherever you want.
Regarding your 2nd question: there are multiple timer sources, but only one is suitable for interval timing, that is, channel 0. IBM-compatibles still comply with the system timer layout shown above. They retain the same functionality, but might add more on top of that or change how the hardware works and how it's packaged. Nowadays, additional timers do exist like high-resolution timers, but using them for interrupt timing instead would break compatibility.
Intel 8253 Datasheet
Intel 8254 Datasheet
IBM PC Technical Reference
IBM PC AT Technical Reference
Can the kernel set the interval of the hardware timer, or is the interval a fixed number that can't be changed programmatically?
Your questions are ENTIRELY processor specific. Some processors have controllable timers. Others have timers that go off at fixed intervals. Most processors you are likely to encounter have adjustable timers, however.
Does the CPU have a dedicated hardware timer for scheduling or is there many hardware timers, and the kernel can choose whichever timer it wants to use for scheduling?
Some processors have only one timer. Most processors these days have multiple timers.
A timer is used for CPU protection. What mechanism is the timer used to compute actual current time in the PC?
Almost all modern computers have a built-in real-time clock, which keeps rough track of the time even while the computer is off. The computer can simply read from the RTC to get the current time.
It is possible to make real time intervals in not Real-Time Linux application in C/C++?
I'm writing a ADC simulator. This is an application that generates packages with certain frequency. It is important that the frequency of package generation as closely as possible corresponded to the sampling rate of ADC. Why I don't want to use sleep() and usleep() to set package generation time intervals.
Thanks.
It is possible to make real time intervals in not Real-Time Linux application in C/C++?
No... if it were, it would be a Real-Time Linux system.
That said, you can probably get very close, so it depends on your intervals and tolerances. Your only serious option for sub-timeslice precision is to nail the sending thread to a core and let it spin, while keeping other processing off that core, but that's very wasteful of hardware....
If you can afford to have latencies long enough for your sending code to be re-scheduled then you can look at setting up alarms & signal handlers, but that's potentially massively higher latency, perhaps only on relatively rare occasions where the cores have all been otherwise utilised. To assess how well this works, you've got to do real measurements under realistic system loads.
The packet generator shouldn't be with the packet sender.
If you want the packets to be sent on time, you should create the packets before hand, and send them to the packer sender.
So you need a thread with a work queue, and use a sleep on that thread to send the packets on time. (you can look a boost's sleep())
I have a kernel module I've built that requires at least 1 ms time resolution. I currently use do_gettimeofday() but I'm concerned that this won't work once I move my module to an embedded device. The device has a 180 Mz processor (MIPS) and the default HZ value in the kernel is 100. Thus using jiffies will only give me at best 10 ms resolution. That won't cut it.
What I'd like to know is if do_gettimeofday() is based on the timer interrupt (HZ). Can it be guaranteed to provide at least 1 ms of resolution?
Thanks!
ms is not microsecond, it's millisecond. Without knowing more about your choice of device, no one can possibly answer such an implementation-dependent question as whether gettimeofday is based on the timer interrupt. If you have chosen a device, which knowing the instruction set and clock speed suggests, then why don't you look at the implementation of that particular kernel to find out?
On an embedded device, it can't be guaranteed. Seeing as it's MIPS based, it's probably OK, most MIPS machines have cycle counters. But, you're going to have to go read the source to that part of the kernel to see what it is doing on your platform.
Yes, you need to enable CONFIG_HIGH_RES_TIMERS in your kernel, and make sure that your platform registers a clock_event_device. This is the mechanism that allows to expose high-resolution timers to userspace. You can check the resolution of your timers by calling clock_getres() in userspace.
Is it possible to sleep for an amount of time that will be accurate to less than 100 microseconds on Windows CE? The less jitter the better - ideally we'd like single digit microsecond response times.
What we really want is a 5ms timer with very low jitter - although the Windows CE WaitFor[Single|Multiple]Objects and Sleep APIs work in units of milliseconds, we can't then correct for the sub-ms time our code may take to run, so the cycle would gradually drift.
If this is not possible, that information would be very helpful too.
This MSDN article has some code to set up a 500us timer interrupt in WinCE, so it's absolutely possible.
If you aren't locked into your version of WinCE, you might want to look into Tenasys, who claims to offer an RTOS running side-by-side with Windows on standard hardware.
I've also heard good things about QNX, but I haven't used their products either. I do not believe it is Windows compatible in any way, however.
It's not possible. It's not even possible on desktops. Typical operating systems simply don't function in this manner.
If what you need is something to fire precisely every 4 milliseconds or whatever you're out of luck. If what you really need is something to fire precisely 250 times every second that may be more doable. If you're in need of the latter I can suggest an approach.
If your need to sleep is not a battery/thread-yield issue and just a matter of accurate timing, you can use the "performancecounter" in Windows CE devices. On XScale and Qualcomm CPUs, this is the internal chip timer and has sub 1-ms granularity. On older OMAP and Samsung processors, the performancecounter API is passing through the 1ms system tick and has lots of jitter.
L.B.
To correct the jitter you need access to a high resolution timer.
The CPU you have may have one. If not, the interrupt controller may.
The Easiest way is to use a Linux with realtime and WINE your way into that library.
you want a Periodic Thread.
Take a look at this report from NIST.