Hello,
> > When using 32768 bytes MTU I can get around 190 Mbps out from a PIII 450.
> > (and only 190 Mbps because the two frontends have fast ethernet cards)
> > So why this is so bad? If the other end can keep up, it will increase
> > throughput.
> And you could get even better by getting rid
> UDP is still a bad bet for reliable request response. It's
> really dumb to effectively reimplement TCP without windows on
> top of UDP just to avoid using TCP.
well said
randy
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Crist J. Clark wrote:
> On Sun, May 19, 2002 at 10:25:18AM -0700, Michael Sierchio wrote:
> [snip]
>
>
>>Back to problem of NFS over UDP -- it's not so stateless, is it? ;-)
>>Remote disk access is mostly bulk transfer operations anyway,
>
>
> A _lot_ of remote disk access is not bulk transfer
On Sun, May 19, 2002 at 10:25:18AM -0700, Michael Sierchio wrote:
[snip]
> Back to problem of NFS over UDP -- it's not so stateless, is it? ;-)
> Remote disk access is mostly bulk transfer operations anyway,
A _lot_ of remote disk access is not bulk transfers, but file status
information.
--
C
Terry Lambert wrote:
> UDP is still a bad bet for reliable request response. It's
> really dumb to effectively reimplement TCP without windows on
> top of UDP just to avoid using TCP.
Speaking as someone who has implemented reliable message protocols
over UDP about a dozen times, I can affirm T
Joshua Goodall wrote:
> On Sat, May 18, 2002 at 05:48:19PM -0700, Terry Lambert wrote:
> > Joshua Goodall wrote:
> > > On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> > > > No. TCP. RPC over UDP is really a silly idea. If you need
> > > > reliable delivery, then don't use a pro
On Sat, May 18, 2002 at 05:48:19PM -0700, Terry Lambert wrote:
> Joshua Goodall wrote:
> > On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> > > No. TCP. RPC over UDP is really a silly idea. If you need
> > > reliable delivery, then don't use a protocol with "unreliable"
> > > as
Joshua Goodall wrote:
> On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> > No. TCP. RPC over UDP is really a silly idea. If you need
> > reliable delivery, then don't use a protocol with "unreliable"
> > as the first word of it's name. 8-).
>
> UDP may well be perfectly viable
On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> No. TCP. RPC over UDP is really a silly idea. If you need
> reliable delivery, then don't use a protocol with "unreliable"
> as the first word of it's name. 8-).
UDP may well be perfectly viable as a RPC transport, but Terry's
m
Terry Lambert wrote:
> The really cool thing is that this means I can shout on the wire at
> the right time, cause a collision, and effectively stace an undetectable
> denial of service attack against your servers, by making it drop large
> UDP datagrams IP frags.
This "attack" works against any
Terry Lambert wrote:
> No. TCP. RPC over UDP is really a silly idea. If you need
> reliable delivery, then don't use a protocol with "unreliable"
> as the first word of it's name. 8-).
The U in UDP is for "User". See RFC768.
NFS over UDP works just fine in the majority of cases, and for slow
Attila Nagy wrote:
> > If the card on the receiving could not receive so many back to back
> > packets and looses one or more, nfs will get stuck retrying the same big
> > packet and the same thing happening over and over.
>
> Yep, but that's not my case. If this would be the problem, I guess
> c
Attila Nagy wrote:
> > Sending datagrams bigger than the MTU is a bad idea.
>
> It depends on what do you want to do with that NFS server :)
Sure. Maybe you want to use up it's mbufs by jamming the frag
reassembly queue for IP full of N-1 frags using 64K USP packets.
> I want to get out from
Andrew Reilly wrote:
> On Sat, 2002-05-18 at 18:53, Terry Lambert wrote:
> > Sending datagrams bigger than the MTU is a bad idea.
> >
> > I would be real tempted to drop the packets and send "don't fragment"
> > ICMP responses to beat up anyone who abused UDP by sending larger
> > than the MTU.
>
Hello,
> If the card on the receiving could not receive so many back to back
> packets and looses one or more, nfs will get stuck retrying the same big
> packet and the same thing happening over and over.
Yep, but that's not my case. If this would be the problem, I guess
changing from gx to em wo
Hello,
> Sending datagrams bigger than the MTU is a bad idea.
It depends on what do you want to do with that NFS server :)
I want to get out from that several hundred megabits per second, so I
can't use <1500 bytes MTU.
Just for comparison:
when using <1500 bytes MTU (as close as possible to the
On Sat, 2002-05-18 at 18:53, Terry Lambert wrote:
>
> Sending datagrams bigger than the MTU is a bad idea.
>
> I would be real tempted to drop the packets and send "don't fragment"
> ICMP responses to beat up anyone who abused UDP by sending larger
> than the MTU.
>
> I guess this is about Linu
> Attila Nagy wrote:
> > > > the "em" driver (if "gx" is already in the initial plan), because it
> > > > reportedly works better (for example I couldn't do NFS serving with UDP
> > > > packets bigger than the MTU with that, while the "em" driver works OK).
> > >
> > > It *does* frag packets bigge
Attila Nagy wrote:
> > > the "em" driver (if "gx" is already in the initial plan), because it
> > > reportedly works better (for example I couldn't do NFS serving with UDP
> > > packets bigger than the MTU with that, while the "em" driver works OK).
> >
> > It *does* frag packets bigger than the M
Hello,
> > the "em" driver (if "gx" is already in the initial plan), because it
> > reportedly works better (for example I couldn't do NFS serving with UDP
> > packets bigger than the MTU with that, while the "em" driver works OK).
> It *does* frag packets bigger than the MTU, right?
netstat didn
Attila Nagy wrote:
> Although I'm not a coder myself, I would also look for the way to patch
> the "em" driver (if "gx" is already in the initial plan), because it
> reportedly works better (for example I couldn't do NFS serving with UDP
> packets bigger than the MTU with that, while the "em" driv
On Fri, 17 May 2002, Kenjiro Cho wrote:
> ECN support in TCP is independent from ALTQ, and it can be done
> separately.
> An ECN patch for 4.5 which doesn't require ALTQ is included in
> altq-3.1. It's been in KAME since December.
> If there are interests, I can make a patch for -current.
Pers
Hello,
> ECN support in TCP is independent from ALTQ, and it can be done
> separately. An ECN patch for 4.5 which doesn't require ALTQ is included
> in altq-3.1. It's been in KAME since December. If there are interests,
> I can make a patch for -current.
I think it would be very good to catch u
Adrian Penisoara wrote:
> On Fri, 17 May 2002, Attila Nagy wrote:
> > >We have started a "ALTQ integration in FreeBSD" project which is
> > > headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD
> > > 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been
> >
Hi,
On Fri, 17 May 2002, Attila Nagy wrote:
> >We have started a "ALTQ integration in FreeBSD" project which is
> > headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD
> > 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been
> > advised and we have receive
Hello,
>We have started a "ALTQ integration in FreeBSD" project which is
> headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD
> 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been
> advised and we have received on principle approval. We are looking for
>
We have started a "ALTQ integration in FreeBSD" project which is
headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD
5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been
advised and we have received on principle approval. We are looking
for help with committ
27 matches
Mail list logo
