[rescue] bootp and dhcp - conflict?

[Dan Moisa]

Thanks for the replies - I've tried the instructions here -
https://www.netbsd.org/docs/network/netboot/finish.html
It's clearly a problem *after* the kernel loads and starts mounting
file systems, before that it loads pretty fast. The issue right now is
that just adding the options doesn't have an impact. I can't even boot
past rebuild font cache, much less configure and compile a new kernel
with the new options. Even running vi takes 2 minutes to load off
network, it's that bad.
Either I figure out how to give it the params, or cross-compile a
kernel? I can't tell if this is something I can set on the server
side. I'll try tcpdump to see what's going on.

On Thu, May 5, 2022 at 10:07 AM Mouse <mouse at rodents-montreal.org> wrote:
>
> >>> All's good now, net booting like a pro with slowest speeds ever,
> >>> anyone happen to have some magical nfs parameters that makes this
> >>> faster?
> >> Biggest impact on speed will probably be wsize=16384,rsize=16384
>
> Yes and no.
>
> I've seen cases where smaller rsize/wsize help; I've seen cases where
> bigger rsize/wsize help.
>
> I even saw one case where rsize=1024 made it work whereas the defaults
> caused _some_ reads to hang forever.  In that case it was partially an
> underlying network issue.  (The server could handle 60-octet packets;
> the client would drop anything shorter than 64 octets.  Ethernet, IP,
> and UDP headers would push a packet over 64, but the last frag of a
> fragmented packet could be <64 octets, in which case the server would
> send it, the client hardware would drop it, IP reassembly timed out,
> repeat forever.  With rsize=1024, data packets never got fragmented.)
>
> In the case at hand here, large wsize and rsize could actually break
> things in a different way.  If the client network is slower than the
> server (eg, a 10Mb SPARCstation served by something running gigabit), a
> many-fragment packet can consistently lose a fragment to lack of
> buffering in the intervening network.  rsize=16384 leads to at least 11
> frags (possibly more; I haven't done the detailed arithmetic, but the
> payload alone forces at least 11 frags), which, depending on the
> infrastructure, could well lead to at least one of them getting
> consistently dropped when the fast sender overruns the slow consumer.
>
> Though, technically, I suppose that _would_ have a big impact on speed.
> Just not the kind of impact you want. :-)
>
> As for the original speed issue, the first thing I'd try is tcpdumping
> on both the client and the server, then comparing the captures to see
> if anything is getting lost.  (Or etherfind or whatever, if one or both
> are running OSes without tcpdump.)
>
> /~\ The ASCII                             Mouse
> \ / Ribbon Campaign
>  X  Against HTML                mouse at rodents-montreal.org
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>
> _______________________________________________
> rescue list - http://sunhelp.org/mailman/listinfo/rescue_sunhelp.org