The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: George Michaelson <ggm@algebras.org>
To: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] Cole's Slaw
Date: Thu, 10 Dec 2020 13:10:18 +1000	[thread overview]
Message-ID: <CAKr6gn2nbW9sBVznHpsw9PUFsckM1WOBy8R4ZgkYmNP1UpMmZw@mail.gmail.com> (raw)
In-Reply-To: <28537.1607561596@cesium.clock.org>

I deployed cheap switches, to try and reduce contention on the WiFi
segment in a 3bed flat. I suspect, switching is *slower* than good
quality 4/5G. I deployed cheap unmanaged switches. I think I may need
to re-consider. (it may be slower than good quality 5gz WIFi but I
felt not, lots of concrete, so I went cables in walls. Professionally
installed cables too)

old cheap switches have high port speed, but low cross-backplane
bandwidth. They basically don't do what they say on the label although
I have no proof, my observation is that 100mbit is rarely achieved on
a cheap switching backplane. I think most people won't notice. If you
need to do the full-disk restore, or stream 4K at the same time as
play some call-of-duty *and* do a full-disk streaming restore, I think
you can destroy your cheap home switch quickly. I have been prepping a
ZFS filestore and I calculate I'm getting 30mbit-sec end-to-end from
300mbit capable backplane hosts. The port speeds are gig. The actual
capability once you get over the Raspberry Pi USB3 is a LOT less. (the
receiver is a Pi4 with 8GB of memory, it should *not* be disk I/O
bound)

my various OSX Macs can do roaring speeds if you back-to-back connect
them. Put them into the switching stuff, it drops off really quickly
to boringly slow speeds.

If you go out the fibre router to the public network, I think their
contention model remains interesting: Stuff is being done in layer 2
to manage your bandwidth and the fibre which is capable of gig, is
probably doing bizarre things to pretend to be slower. Forced
bit-drop, random drop, long stalls. The framing at layer2 is really
bizarre. they can do a LOT in layer 2, they don't talk about. we're
all some kind of PPPo<something> inside this, which feels pretty meh.
Why did it have to be like this?

Economies which (unlike Australia) don't do bandwidth limit for
pricing disfunction, probably are saying :what do you mean: at this
point. (The UK, you can get true gig to the home. Parts of the USA
likewise. Lots of europe likewise. Here in Oz, although the bearer is
capable, you can't afford the price they want to charge because they'd
doing ROI sums to pay back $50b of spend, as quickly as possible)

If your router is running the Broadcom chipset most of them are built
around, Its switch is not really very big, in buffer space.  My R7000
is a  Broadcom BCM4709A0 and I don't think its doing very well.

So, I'm dying inside because this is highly contestable FUD. If
somebody with shares in the vendors chipset can tell me "you're just
wrong' I'd believe them but my experience from the field is, white box
domestic switches, and home routers, simply can't "do" full-bore gig
on multiple paths across the switch at once. Ubiquity and other good
vendors? Probably fine. Hell, for all I know, even Mikrotik might be
ok, I've only ever had their toss-away freebies from conference Schwag
and it was cool to have a box the size of a packet of cigarettes which
run BGP, but they felt pretty slow (they even do portspan. amazing
stuff)

-G


On Thu, Dec 10, 2020 at 10:53 AM Erik E. Fair <fair-tuhs@netbsd.org> wrote:
>
> I bet your backups across the gigabit switch to your NAS are (small) incrementals.
>
> You'll care about having 10gigE when you try a restore from backup.
>
> We have a very persistent problem with storage capacity versus I/O bandwidth, which I metaphor as "swimming pools of data, which we fill & drain with garden hoses." How many terabytes of stable storage do you have at home?
>
> Further, LANs have always lagged local I/O bandwidth (across PCI, PCIe, etc), independent of the nastiness introduced by latency and less-than-ideal data transfer protocols. Unix "diskless" workstations were only tolerable because the disks were still expensive and there were good reasons to share.
>
>         Erik

  reply	other threads:[~2020-12-10  3:11 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09  4:35 [TUHS] Were cron and at done at the same time? Or one before the other? M Douglas McIlroy
2020-12-09 15:40 ` Clem Cole
2020-12-09 15:46   ` Niklas Karlsson
2020-12-09 16:01   ` Bakul Shah
2020-12-09 16:11     ` Clem Cole
2020-12-09 17:05       ` Bakul Shah
2020-12-09 17:42         ` Dan Stromberg
2020-12-09 23:46           ` Nemo Nusquam
2020-12-14 20:28     ` Dave Horsfall
2020-12-14 22:23       ` Thomas Paulsen
2020-12-14 23:04         ` Andrew Hume
2020-12-14 23:59       ` Harald Arnesen
2020-12-17  4:08         ` John Cowan
2020-12-15  2:57       ` Bakul Shah
2020-12-15  3:05         ` Warner Losh
     [not found]   ` <CAC20D2PXZY9aWgDf-RknROs6JbKEUjzbQ2BRzfTgTR07pXni3g@mail.g mail.com>
2020-12-09 16:04     ` John Foust
2020-12-09 16:40   ` Warner Losh
2020-12-09 16:53     ` Jon Steinhart
2020-12-09 16:58   ` Theodore Y. Ts'o
2020-12-09 19:58     ` Dan Cross
2020-12-09 20:30       ` Will Senn
2020-12-13  1:07       ` Theodore Y. Ts'o
2020-12-13  1:56         ` Jon Steinhart
2020-12-13  2:58           ` Theodore Y. Ts'o
2020-12-13  3:07             ` Jon Steinhart
2020-12-13 16:49               ` Theodore Y. Ts'o
2020-12-13 19:06                 ` [TUHS] Were cron and at done at the same time? Or one before the other? [ really linux and filesystems ] Jon Steinhart
2020-12-13  3:02         ` [TUHS] Were cron and at done at the same time? Or one before the other? Dan Cross
2020-12-09 23:22     ` Bakul Shah
2020-12-09 23:44       ` Steffen Nurpmeso
2020-12-09 23:51         ` Steffen Nurpmeso
2020-12-10  0:19   ` [TUHS] Cole's Slaw John Gilmore
2020-12-10  0:29     ` Larry McVoy
2020-12-10  0:53       ` Erik E. Fair
2020-12-10  3:10         ` George Michaelson [this message]
2020-12-12 21:11       ` Dave Horsfall
2020-12-10  1:49     ` John Cowan
2020-12-10  2:12       ` Jon Steinhart
2020-12-12  2:56   ` [TUHS] Were cron and at done at the same time? Or one before the other? Dave Horsfall
2020-12-12 19:10     ` scj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKr6gn2nbW9sBVznHpsw9PUFsckM1WOBy8R4ZgkYmNP1UpMmZw@mail.gmail.com \
    --to=ggm@algebras.org \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).