em. igb performance test
Nomad Esst
noname.esst at yahoo.com
Sun Sep 6 05:27:20 UTC 2015
Thanks for your reply. How can I solve this problem? e.g. speed up the link negotiation, buffer the packets while link negotiation is being done ? Any ideas?
Regards.
On Saturday, September 5, 2015 8:01 PM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
Hi,
It's likely a combination of STP and how long it takes to do link
negotiation. Packets transmitted during link negotiation will be lost.
-adrian
On 5 September 2015 at 08:03, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:
> On Sat, Sep 05, 2015 at 02:45:28PM +0000, Nomad Esst via freebsd-hackers wrote:
>
>> Hi allDuring some performance tests, we found out some weird problems. We use a shell script that do the following :
>> do from 1 to 10Shutdown em/igb interfacesleep 3Bring em/igb interface uptcpreplay -i em0 -l ospf_hello.pcap sleep3end
>> By running this shell on one side we expect 10 ospf hello packets to get arrived at the other side, but tcpdump (on the other side) shows 4, sometimes 8 and etc ... (not all 10 packets are arrived at the other side).We test this scenario with a Cisco router, and all packets are received at the Cisco side. What causes this packet loss in FreeBSD (maybe in em or igb drivers)?I know that this scenario may not have any use in the real world, but I'm curious, why Cisco don't have such behavior.Thanks in advance.
>
> uping interface not momentaly.
> packets sending to down interface will be lost.
> try to wait `status: active` before run tcpreplay.
> Also, check STP off on interconnect switch you port.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
More information about the freebsd-hackers
mailing list