richlowe: I'm slowly forcing myself to accept that touch scrolling now works backwards from what I learned all because Apple decided it should and now everyone has matched...

@Kurlon you can swap MacOS-matches-iOS scrolling via system prefs rather easily... if I don't migrate my homedir to a new mac, I have to do this by hand on a new one.

I had been doing that, but now that Windows is also defaulting to the other way, rather than change every system I sit at, I'm forcing myself to adapt.

Similarly... tap to click... gah, hate it, but it's not going away...

if you set -mtu on a route to a value below the interface (that'd be used) mtu, will tcp pick that up for it's MSS for anything using that route?

Continued lab testing, best I can squeeze out of my dual 82599 10Gb aggr between a Westmere pair is 12.4Gb/s with iperf3.

For giggles, switched one node to Ubuntu 22.04, that was horrifically bad, perf sank down to around 6Gb/s with wild swings.

@jbk I think so? Easy enough to test... lemme try.

Yeah... works on my test (latest SmartOS release). gist forthcoming...

@jbk ^^^

Other datapoint for today, DDR3 @ 1333Mhz vs 800Mhz doesn't appreciably alter NFS speed on my Westmere gen crud so worth the downclock for extra arc space.

Now to do some testing against my prod box to see why it's so dang slow.

jbk: yes, definitely. One of the things I did at google used route mtus (on linux) to enable a seamless migration to a larger MTU on google's internal network. Interface gets max, default gets mtu 1500, destinations in between got a topology-dependent mtu

hrm.. wonder if that might work here..

although, if our interface is already set for 1500, that should already use that, right?

we have a situation w/ a poorly configured customer network where some ports are set to 9000 and some aren't

we can't fix that, they won't fix that for reasons

but some of those systems using 9000 mtu are having issues talking to our stuff..

(same vlan, but different switches)

jbk: ouch.

yeah, it's annoying to say the least

So what *should* happen for TCP is that interface MTU, route MTU, and peer's advertised MSS all constrain the sender's packet size. I haven't stress-tested this on illumos (haven't tried enabling jumbograms on my home network..)

but non-TCP traffic doesn't have the MSS negotiation.

it should be tcp (thankfully)

Worrying about this is why I've never gone to jumbo MTUs, if I could default to 1500 save for specific local hosts in subnet...

Ooofh, perf with this Mellanox Connectx-5 is horrid, single stream it's struggling to do 6Gbps over a 25Gbit link.

If I use my X540 node as the sender, I can do better.

have you tried multiple connections?

Yup, pushing TO that box I can do about 13.2Gbps with a pair of X540 10Gb links in a lag to my problem box. (Dual CX5 25Gb in a lag)

Sourcing from the problem box, about 6.5Gbps with 8 streams.

Looking at it via NFS between the boxes, problem box as the server, I can read from arc at 1.4GB/sec, over NFS I top out at 200MB/sec. Pushing to it, I can do 300MB/sec.

That's what got me chasing, I've got a much older 2010 era HP box with far worse specs that did a much better job as a VM NFS host.

My suspicion now is swapping to an X520 and dual 10Gb links I'll get much better nfs numbers out of the box, which is not what I anticipated.