Alimjan Kuramshin wrote: [...] > So, when my device send data to the PC, i'm using the Wireshark > to capture incoming stream,
Okay. > and found those delays, using oscilloscope on TX+/- line i don't > see any delays between the packets, everything just fine. Your oscilloscope is connected to the physical Ethernet cable, correct? > And delay is very strange i guess, By "delay" you mean what? Please define your "delay". When you say there is a 50us delay, where did the 50us value come from? How did you calculate it? What two time values are you subtracting from each other that equals 50us? > for example(delays in us): .. .. 45 46 44 48 49 1200 44 48 44 46 49 > 42 50 1530 .. and number of 'normal' delay between packets is very > vary as delay itself, i can receive 200 packet with delay of 40-60 us 200 * 50us = 10000us = 10ms. 10ms happens to be the approximate timer resolution of the Windows operating system timer, and approximately the maximum amount of CPU time that a thread can consume before the operating system will remove it from the head of the dispatchable threads list to the end of the list to wait for another "slice" of processor time. This is completely normal. > and then i've got huge timeout 1-3 ms, some times much greater, This is completely normal. An interrupt probably occurred or else another higher priority thread's wait completed, and so the system interrupted YOUR thread (WinPCap's and/or Wireshark's) and dispatched the other higher priority thread. Then 1-3 ms later, the other thread finished with what it needed to do and so went back to sleep. The system then dispatched YOUR thread again. Thus a 1-3 ms delay. Again, this is completely normal in ANY multi-programming environment where multiple threads/processes are running. Why are you so surprised by this? > then 1000 packets normal and then again delay, 1000 * 50us = 50000us = 50ms The other threads probably had no work to do for that 50ms interval, so your thread was dispatched again and again. Five times in fact. Then, some other higher priority thread (probably a system thread) needed to do something, causing your thread to be delayed for 1-3ms. This is normal! Nothing you have said so far is anything unusual. It is all completely normal and expected. > so i can't see no logic with it. See above. :) > From this point my question is: is it possible to archive stable > receive with WinPCAP during long period of transfer, i mean stable > capture interval?! Probably not. As long as there are other equal or higher priority threads running on the system (and as long as there are device interrupts occurring that need servicing) your thread WILL be interrupted and experience delay. This is normal multi-task (multi-thread) dispatching behavior and there's largely nothing you can do to prevent it. The ONLY way to prevent it is to ensure your thread is the highest priority thread in the system, but be forewarned: doing so is *dangerous*! If, for example, the system threads that handle keyboard and/or mouse and/or timer and/or disk interrupts, etc, are not ever dispatched because your thread is consuming all available CPU cycles, your system will lock up and become unresponsive. You will have to do a hard power-off. As long as you are using consumer-level hardware and a consumer-level operating system instead of specialized hardware and a real-time operating system, you are going to experience delay. Windows is NOT a real-time operating system, nor was it ever meant to be. -- "Fish" (David B. Trout) [email protected] _______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
