Hi,
Even with EDITCAP the trace file is stay large size 190MB and with zip so cant send it, so will send only the expert info images.
BTW, i changed the nic to Intel Pro 1000 PT Dual port and the problem solved so we have to change nic on another 14 servers.
On Thu, Dec 31, 2009 at 10:12 PM, Guy Harris
<guy@xxxxxxxxxxxx> wrote:
On Dec 30, 2009, at 4:45 AM, Tal Bar-Or wrote:
> i noticed that on Interface Details the Receive but no Buffer is huge and increasing my question is could it be the reason for such latency and lost data, what could be the cause for such huge values.
"Receive but no Buffer" is the value reported for OID_GEN_RCV_NO_BUFFER. Microsoft's description of it:
http://msdn.microsoft.com/en-us/library/bb648558.aspx
says:
As a query, the OID_GEN_RCV_NO_BUFFER OID specifies the number of frames that the NIC cannot receive due to lack of NIC receive buffer space. Some NICs do not provide the exact number of missed frames; they provide only the number of times at least one frame is missed.
That sounds as if it's possible for it to cause those problems. However, if it only happens when you're capturing in promiscuous mode, that's probably *not* the problem, as network adapters are normally *not* running in promiscuous mode, and, if you're on a non-switched network, going into promiscuous mode could significantly increase the number of packets you receive, which might overflow the normal amount of buffering that the network adapter's driver allocates. (If you're on a switched network, you probably won't be sent many packets that aren't broadcast packets, multicast packets, or packets intended for you, so going into promiscuous mode probably won't increase the number of packets you see by very much.)
Attachment:
warning.png
Description: PNG image
Attachment:
dup_ack.png
Description: PNG image
