i'm capturing network packets( a transport stream) along with its arrival time using winpcap library. But I'm facing some issues.Whenever I play audio on my machine or copy a large file from network, the timing information of my captured packets gets distorted.Some packets timestamp are very close to each other while others are a bit far.Is there any solution (software/hardware) to rectify this.I need accurate timestamping of network packets.
You could raise the process priority of the capture application to High using the Task Manager.
But you really need to consider what you are trying to achieve and why. Do you want to know when the packet arrives at the NIC, when it is processed by the kernel, when the kernel places it in the capture program's socket buffer, when the capture program reads it out of its buffer, when the kernel places it in some other programs socket buffer, or when some other program reads it from its socket buffer?
All those time stamps are different, and when the system is under load the differences will necessarily become larger. Timing information from capture program will most likely reflect that time when the capture program read the packet out of its own socket buffer. Increasing the capture application's process priority will make that happen more smoothly, but it will make the handling of packets by any other applications less reliable.
Related
I am working on a project using a Raspberry Pi where I need to create a GUI that can interface with the various peripherals. Specifically the program needs to:
-read the position data from a touchscreen, mouse, or other HID
-perform some math on on the position data
-store the data in a FIFO buffer
-output that data over the SPI port at a fixed frame rate
I have an electronics background, with some experience writing firmware for microcontrollers, but I'm a relative novice when it comes to this kind of stuff. I have done some research, and it looks like the mouse/touchcreen data is available by reading a file in the /dev/input directory, and I assume you can access the SPI port by reading or writing to some file in the /dev directory. (I am currently running Raspbian)
My initial thoughts were to write a simple C program that a) reads the touchscreen data file and stores it into a preallocated buffer in memory and b) writes the data that next in line to the SPI data file in order to write it out to the SPI port. Part (a) would fire off either on a timer interrupt and poll the touchcreen data to see if it's new, or fire off from a "new data" interrupt. Part (b), the SPI part of the program, would fire off at a fixed rate, probably from a timer interrupt.
So my questions are:
-Is it even possible (or easy) to access interrupts or system timers from the user space? I assume you would need to get hooks into the kernel somehow?
-If so, how would I make it so that my function runs whenever a interrupt or timer fires off?
-How easy is it to use the SPI DMA in user space? Does anyone have any experience doing that? I did a little research and it looks like you need to load a custom kernel driver, but I didn't know how tricky that would be.
-Is it possible to write out a parallel word on the GPIOs the way you would do it on a microcontroller (ie all at once by writing the word to the port's output register)?
I know there are plenty of higher level programming languages and wrappers that allow you to talk to the perepherals, but I'm a little hesitant doing it that way since the timing seems pretty tight. I need to output (3) 16-bit words per frame at ~1k frames per second. At 500kHz SPI bitrate, each frame is 96 us long, and at 1k frames per second, each period is 1ms. This is why SPI DMA, or even writing the data out as a parallel word would be a lot easier in terms of timing.
Thanks for the help!
In one of my project, I have a nano-computer (embedded Linux) which is connected to a microcontroller with an UART connection.
Both do some process on their own, but sometimes the nano-computer needs to send data on the UART and vice versa.
I suppose that if A wants to communicate with B, B needs to be listening, right ? How do I know when to listen, and when to talk ?
Do I need to have a special thread running in parallel in both of my devices only responsible for UART communication, while they do other stuff ?
If I missed a message, is there a buffer which is filled that I can read when I am ready ?
Thanks for your advices. :)
'A' and 'B' are listening all time. You have to enable the UART receive interupt.
Maybe this link will explain the basics: UART basics
Connected and initialized correctly the hardware has a tx and rx on both sides tx to rx. So both sides are listening all the time from a hardware perspective. The operating system likely has a driver and a buffer that is accumulating that input all the time. BUT if you have no software that is asking for the data coming in then you wont see it. You do need some software monitoring the uart if you will (through drivers and operating system usually) so that you can see what the other side sends at any given time. You do this on both ends of the connection if that is what is required.
There are two approaches that are used.
In the past, it was common to use hardware flow control. This uses an additional wire in each direction. The sender waits until the wire indicates the receiver is ready. When the receiver is not ready to receive data, it signals the other side. Hardware would buffer at least one byte and, if the buffer was full, signal the other side not to send over this wire.
This is less common today. UARTs are so slow relative to modern hardware and large buffers are so cheap and easy to provide that there is no longer an issue. The sender just fills the receiver's hardware buffer and the receiver empties the hardware buffer periodically. Software would have to ignore the buffer for a long time for it to overflow.
An intermediate solution is to use flow control in the data flow. Generally, two characters are reserved, one to stop the flow and one to resume it. The receiver sends a flow control character to the sender if its buffer is getting close to full and another one if its buffer is getting close to empty. This is really only useful if the data flow doesn't need to handle binary data. This is extremely rare and was traditionally used primarily for connections that had a human on one end. You could also pause the flow if the information was coming faster than you could read it.
Generally, the protocols used are tolerant of overflow and include some form of high-level acknowledgement and/or retransmission as appropriate. One device might wait for the other side to send some kind of response to its command and, if it doesn't get one, retry the command. The protocol is designed not to do anything terrible if a command is received twice since it might be the reply that's lost.
I understand this question has been discussed many times: Should I use libpcap or PF_PACKET (the data link socket) to capture packets?
Based on my research, libpcap is suggested over PF_PACKET almost everywhere, mainly due to its portability.
However, for my current project (which is used in a production system), portability is not a concern at all, all I care about is performance (speed, packet loss ratio). My program is running on CentOS 5.10 (kernel 2.6.18)
As far as I know, libpcap put a timestamp on each packet. Does this cause big performance loss?
Are there other factors that make libpcap unsuitable in a high-speed network?
As far as I know, libpcap put a timestamp on each packet.
No, libpcap gets a timestamp for the packet from the OS packet capture mechanism that it uses - which, on Linux is...
...PF_PACKET sockets.
The Linux kernel time stamps incoming packets. PF_PACKET sockets have multiple ways of reading from them:
regular socket receives, for which you can either get a time stamp with an explicit ioctl (so you can avoid fetching it to userland, but you can't avoid the kernel time stamping the packet in the first place; libpcap, when using regular socket receives, always asks for the time stamp);
memory-mapped access, which always supplies the time stamp.
Libpcap uses memory-mapped access whenever it's available; if you care about capture performance, you probably want to do so as well. It's not easy to use, however.
Is it possible to open a serial device (such as /dev/ttyS0) and be informed via select/poll/etc... or a signal when the handshaking lines (such as CTS/RTS or DSR/DTR) change? I know at the hardware level there's an interrupt from the UART to tell the kernel it has changed, but can I be informed of that up in userland?
Edit: I am aware of TIOCMIWAIT, but that ioctl call blocks until the status lines change. I would like instead to keep processing generally and have a poll or similar be informed on change, as well as other events.
There's no way to wait for the DTR/RTS lines to change in userland. The only way to do this on Linux is to constantly poll the device, checking to see if the status of the RTS/DTR lines have changed. I generally steal my serial port code from gtkerm, and it polls.
You can try using TIOCMIWAIT, but if I remember correctly that's going to be very tied to the driver for the serial port that Linux is using, and so may not work from driver to driver.
At present we are using Fedora Core 3 for a system we are working on. This system needs to communicate via serial. The timing of communications is timing critical. At present it seems that the serial driver has delays in pushing the data from the 4k fifo into the 16byte hardware uart.
Is there any way in force Linux to treat this action with a higher priority?
Try the using setserial to set the low_latency option.
By default serial ports are optimised for throughput not latency, this option I think lets you change it.
If you have a hard real-time processing requirement, you may be better off using a distribution that's built with that in mind, for example RTLinux.
Consider getting the device vendor to change the protocol to something less stupid where timing doesn't matter.
Having a timing-critical serial protocol, or indeed one which requires you to acknowledge one message before sending the next, is really stupid.
rs232-style serial ports are really slow, and anything which makes them worse is a bad idea.
I wrote a program to control a device which had a stupid protocol - each byte of data was individually acknowledged (duuh!) and the next one wasn't sent until the ack arrived - which meant that the data transfer rate was a tiny fraction of what it should have been.
Look at the zmodem protocol, for example, which is less stupid.
Better still, get the vendor to enter the 1990s and use USB.