Freezes in communication on Intel PRO/1000 PF Server Adapter

[RRylt]

I have a networking issue, which I have problems in troubleshooting and I would appreciate any idea and feedback.

We have a box dedicated for specific communication with remote server over dedicated fiber line. On our side we have Intel PRO/1000 PF Server Adapter with a gigabit link. Intel Driver Update utility shows latest drivers and the operating system is Windows 7 Pro x64.

Product Detectedhttp://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=18713 Intel(R) 82572EI based Network Controller(OEM)Current Driver Installed9.13.41.0Your driver is current.

Bandwidth utilization and CPU load both are somewhere near 1% and never go much higher than this.

The application continuously receives the data and here is the problem. From time to time, a few times hourly there would be a freeze for up to several seconds and after it, the application would receive a large block of data, as if the was a contention and then all the accumulated data is finally delivered.

It is assumed that remote side delivers data in a good fashion without irregularities of the mentioned kind (other clients are not suffering from this issue), is there any way to troubleshoot the problem from our end?

I noticed that adapter configuration includes Interrupt Moderation feature which seemed to be relevant and I tried to use low levels, or disable at all. This had no effect on the smoothness of received data.

I would really appreciate any suggestions on the issue, thanks.

[idata]

Hi roman921 -

When you say "freeze up" do you mean the whole computer (i.e., mouse does not move, etc) or do you mean that the network activity drops to 0% and then jumps up to say 10% (just throwing out numbers here) and then will transition back to the normal 1% rate?

Thank you for using Intel Ethernet.

Cheers,

-- miles

[RRylt]

Thank you for attention to my issue. Since the server is in data center and I acces it remotely, I unfortunately cannot clarify other freeze symptomps that may or may not take place there. I can only see the issue retroactively, and from software side it was isolated to TCP socket operation. The application is waiting for data from socket and while normally it receives data in small increments, at the issue time there is a delay and then a large buffers comes in.

For example, time and number of bytes received:

12:47:13.493 184

12:47:13.495 280

12:47:13.497 274

12:47:13.497 179

12:47:13.503 319

12:47:13.514 274

12:47:13.518 185

12:47:13.518 259

12:47:13.519 185

12:47:13.519 180

12:47:13.519 185

12:47:13.527 184

12:47:13.529 264

12:47:13.532 179

/* Here comes a delay of 0.77 seconds */

12:47:14.303 280

12:47:14.304 84713

12:47:14.306 272

12:47:14.306 272

12:47:14.321 179

...

This pattern repeats all the time: a delay, then a small "normal" buffer is received and next to it there is a large buffer, which may refer to several seconds of traffic.

[idata]

Hi roman921 -

That is definitely odd pattern you are seeing there. I would recommend that a network sniff be taken for this connection and see if there is any packet loss or retransmission going on during this pause in the traffic. There are a number possible causes including an intermediate switch dropping frames (this is normal for some switches through an algorithm called RED or other associated algorithms) to an issue with a card.

@ MarkH - would you recommend any additional action for roman921?

Cheers,

-- miles

[RRylt]

Thanks, I will try to use sniffer to get some details. Apart from that, is there any chance that hard drive activity affects in some way networking, such as throttling. It was a pure guessing but I did have a suspicion that there is a correlation between peak disk activity and communication delays. Anyway, I am going to use sniffer to gather more information, thanks for your help.

[Mark_H_Intel]

If the data being transferred is being written to a hard drive then that could be your bottleneck. If you run short on physical RAM and end up with pages being swapped between RAM and the hard driver, the bottleneck could be made worse.

Once you look at the Ethernet trace, you might have a better idea about whether the network connection itself seems to be working properly.