Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Sep 2015 08:40:57 +0000 (UTC)
From:      Nomad Esst <noname.esst@yahoo.com>
To:        Adrian Chadd <adrian.chadd@gmail.com>
Cc:        Freebsd Hackers List <freebsd-hackers@freebsd.org>
Subject:   Re: em. igb performance test
Message-ID:  <210203157.2313294.1441528857993.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <CAJ-VmonRC3BeEqPnX1_5R5EP83=Qc_J-n1egvLrjk5eWRvAwdQ@mail.gmail.com>
References:  <CAJ-VmonRC3BeEqPnX1_5R5EP83=Qc_J-n1egvLrjk5eWRvAwdQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Thank you allWe've recently found out that if we change the media type to 10BaseT all ten packets are arrived. And if we change the number of packets to 2 in tcpreplay like
tcpreplay -i gbeth0 -l 2 ospf_hello.pcap

at least 1 packet is arrived at the time (while the media type is 10BaseT and auto negotiation is disabled). but sometimes the second packet is missed.
Adrian, you said that someone is working on adding a buffer to queue the packets until the interface come up. How can I contact with him/her?
Regards. 


     On Sunday, September 6, 2015 1:00 PM, Adrian Chadd <adrian.chadd@gmail.com> wrote:
   
 

 Hi,

I can imagine someone hacking up driver support for buffering up to
'n' packets until the link comes up, or timing them out if the link
doesn't come up in time. Thing is, bringing an interface up doesn't
guarantee it'll be up and live by the time the next command is run.
The cleanest way to get some clean behaviour here is to wait until the
link shows active before running the next command.

hth,


-adrian


On 5 September 2015 at 22:24, Nomad Esst <noname.esst@yahoo.com> wrote:
> 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@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@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@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
>


 
   
From owner-freebsd-hackers@freebsd.org  Sun Sep  6 08:54:08 2015
Return-Path: <owner-freebsd-hackers@freebsd.org>
Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 121849CB5A9
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Sun,  6 Sep 2015 08:54:08 +0000 (UTC)
 (envelope-from freebsd-hackers@dino.sk)
Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72])
 (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 8A8571CD8
 for <freebsd-hackers@freebsd.org>; Sun,  6 Sep 2015 08:54:06 +0000 (UTC)
 (envelope-from freebsd-hackers@dino.sk)
Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan)
 by mailhost.netlabit.sk with ESMTPA; Sun, 06 Sep 2015 10:48:53 +0200
 id 0041C53F.55EBFDF5.00009503
Date: Sun, 6 Sep 2015 10:48:52 +0200
From: Milan Obuch <freebsd-hackers@dino.sk>
To: freebsd-hackers@freebsd.org
Subject: Re: Mount NetBSD partition/slice
Message-ID: <20150906104852.3c4a6254@zeta.dino.sk>
In-Reply-To: <55EBF5C1.2050906@gmx.com>
References: <55EBF5C1.2050906@gmx.com>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; i386-portbld-freebsd10.1)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>;
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Sep 2015 08:54:08 -0000

On Sun, 06 Sep 2015 01:13:53 -0700
Don whY <Don.whY@gmx.com> wrote:

> Hi,
> 
> I've pulled the media from my NetBSD systems (6.x?) before moving to
> FreeBSD (9.2).  The goal was to set up FreeBSD-based appliances and
> maintain them from FreeBSD *systems*.
> 
> However, I've been having a tough time getting FreeBSD to play nice
> with the NetBSD media.  A bit of research indicates that there is
> no support for these incompatible volume formats.
> 
> So, I can either rebuild one of more NetBSD systems and pull all
> the data across a network connection.  This could be tedious as
> there are 10-12 slices of significant size on each volume.  (I had
> hoped to just install the drives in the FreeBSD boxen and cp(1) the
> contents of the volume at bus speeds.)
> 
> Or, just rebuild the NetBSD systems and make NetBSD-based appliances
> (i.e., abandon FreeBSD).
> 
> [I'm not an OS zealot; I'm just looking for something that *works*
> with the least amount of wasted effort/time]
> 
> Have I missed some "trick" to coax NetBSD into *reading* these
> volumes?
> 
> Thanks!
> --don
>

What does 'gpart show' under FreeBSD say? I did not test NetBSD for a
long time, but maybe there is some solution for you...

Milan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?210203157.2313294.1441528857993.JavaMail.yahoo>