Will soon get my new 8-port GB-switch, and from what I've heard without jumbo frames you dont notice THAT much of a difference.

I guess its best if all devices on the same subnet use the exact same MTU-setting for the frames...right? Jumbo frames ain't something magical, its just the ability to set a higher MTU-value....right again?

So, had a look in Vista and I can set as highest 7KB MTU (6KB 5KB 4KB....).
I guess that doesn't mean 7000 byte, but rather 7168 bytes???

So, do I just run "ifconfig vr0 mtu 7168" on my OpenBSD and thats it?
How do I even know 7168 is a supported size on that NIC?
My Vista machine didn't go higher than that for example, maybe others just go to 6KB or 5KB or....???

What will happen if the values dont match correctly, is it just bad performance or will I loose connection to my BSD-server until all partys have the exact same value entered?

Might have the BSD-machine on its own subnet (either VLAN or a totally separate interface and then jumbo frames wont do any good I guess, through the router, but I'll see how I'll set it up).

Jumbo frames are very driver dependent. There's no real standard for MTU values above 1500 bytes, each vendor does it their own way. For Jumbo Frames to work correctly, every device (NICs, switches, routers, etc) on the network has to use the same value.

Ok.
Its hard to know what windows will set MTU to if you choose 7k as was the highest possible on my Vista-machine....will it be 7000, or will it be 7x1024?
Who knows
Anyway, my OpenBSD machine only got 100Mb (and doesn't need more, only got 4GB drive in it too) so jumbo-frames doesn't even seem to be supported then. Better put it in its own VLAN or own physical interface, so the jumboframes goes through a router before reaching it. If I manage to set up jumbo-frames between the three windowsmachines that is....

Will soon get my new 8-port GB-switch, and from what I've heard without jumbo frames you dont notice THAT much of a difference.

actually you should see a noticeable difference even without adjusting the MTU from the standard 1500 (1518 considering CRC and header.)

Quote:

Originally Posted by Seb74

I guess its best if all devices on the same subnet use the exact same MTU-setting for the frames...right? Jumbo frames ain't something magical, its just the ability to set a higher MTU-value....right again?

You are correct that "its best." If the machines are connected via this new-fangled switch you mention, then the switch itself needs to be able to accept frame sizes as large as the machines that are trasmitting to it. If this is not the case, the result will be that the frames larger than the configured port(s) on the switch will be dropped by the switch. This can have precarious and unintended consequences. I don't know personally whether a switch would break down large frames it can handle from one host before transmitting them to another host that isn't configured for that frame size, but it's my opinion that it should (at least on the 'nicer' switches.) This also assumes the switch in question can adjust MTU size per port, as opposed to a global mtu setting, which many cannot do.

Quote:

So, had a look in Vista and I can set as highest 7KB MTU (6KB 5KB 4KB....).
I guess that doesn't mean 7000 byte, but rather 7168 bytes???

This article suggests that with an 'elevated command prompt' you can set the MTU for an interface on Vista in terms of bytes, not KB. Again, be mindful of header and CRC for padding.

Quote:

So, do I just run "ifconfig vr0 mtu 7168" on my OpenBSD and thats it?
How do I even know 7168 is a supported size on that NIC?
My Vista machine didn't go higher than that for example, maybe others just go to 6KB or 5KB or....???

You know what size MTU a particular NIC supports by researching it's capabilities via NIC vendor documentation. As stated previously, NIC MTU sizes vary greatly, and not just from vendor to vendor, but also intra-vendor (model to model from same vendor.)

If your OBSD box was the switch itself, then it's not bad to set the MTU higher than anything that directly connects to it (This would also assume the OBSD switch would primarily be passing traffic from host to host, not originating much on it's own, and what it does originate is not too large for the attached hosts.) However, since you are getting a shiny new switch (what vendor/model?) then you will be better served by matching MTU sizes with the other hosts that will connect to the switch.

Quote:

What will happen if the values dont match correctly, is it just bad performance or will I loose connection to my BSD-server until all partys have the exact same value entered?

You likely won't lose the connection itself, just those frames transmitted from one host to another that are too large for the receiving host. Simple pings likely wouldn't reveal this vulnerability until you adjusted packet size up.

Quote:

Might have the BSD-machine on its own subnet (either VLAN or a totally separate interface and then jumbo frames wont do any good I guess, through the router, but I'll see how I'll set it up).

Respectfully, I have no idea what you are talking about with that last comment. Basically, research the MTU capabilities of all the NICs of all the hosts connecting to the new switch, research the MTU capabilities of the switch itself, then set the MTU to a high level that isn't too high for any of the players and you should have much joy.

The BSD-machine only got 100Mb so from what I've heard you cant set jumboframes on it (that is you cant change MTU upwards much at all I guess). Will very likely have it on its own routerinterface or VLAN so the jumboframes will be repackaged in the router anyway.

I tried running that command in Vista, but it gave me two outputs (one with MTU 1500 and another with MTU something very very large. Didn't say if my regular interface (the 1500 one) was subinterface 0 or 1 or 2, so feels scary changing MTU of subinterface 1 without knowing what interface that is.....I'll google some on it, might be able to set it within the registry or something, or just change it in gui to 7000K and then go check if it did set it to 7000 or 7x1024
One of my XP-machines only have Enable/Disable too choose for Jumbo Frames, so there indeed I have to set the MTU through CMD/Registry/whatever google will tell me.

The BSD-machine only got 100Mb so from what I've heard you cant set jumboframes on it (that is you cant change MTU upwards much at all I guess). Will very likely have it on its own routerinterface or VLAN so the jumboframes will be repackaged in the router anyway.

I tried running that command in Vista, but it gave me two outputs (one with MTU 1500 and another with MTU something very very large. Didn't say if my regular interface (the 1500 one) was subinterface 0 or 1 or 2, so feels scary changing MTU of subinterface 1 without knowing what interface that is.....I'll google some on it, might be able to set it within the registry or something, or just change it in gui to 7000K and then go check if it did set it to 7000 or 7x1024
One of my XP-machines only have Enable/Disable too choose for Jumbo Frames, so there indeed I have to set the MTU through CMD/Registry/whatever google will tell me.

1) I read your switch's documenation and saw that it's capable of full-sized Jumbo Frame support - 9,728 for the MTU... that's good. Because it's not originating traffic of it's own in great quantities, it doesn't need to be matched to anything in particular from what the hosts' settings are- you just need to be sure all the hosts in a particular VLAN are set to the same size so one doesn't transmit a frame larger than another can handle, otherwise the receiver of that frame will drop it (if it's the receiver that has the limitation. Frames sent in the other direction will not be effected.)

2) 100 Mbps ports can, in fact, have jumbo frame support- the support for jumbo frames is not a limitation of the 100Mbps, but the specific capabilities of the NIC in question (regardless of it's maximum bandwidth size, 100 or Gig.) This is good in that if you have a bunch of workstations on 100Mbps and a server on Gig and they all run at (let's say) an MTU of 7000 your network will be quite efficient. Again, just make sure that the server (or any host) isn't configured to send frames that are larger than any other host can handle. Not all frames sent from a particular host are sent at the largest size (just the ones where the IP packet encapsulated in the frame is large, and that is effected by the application, the data sent by the application, and (for TCP in particular) the TCP/IP window size at that moment in time for a particular connection transmition), but those that are need to be sent to recipients that can receive frames that large.

3) I could be wrong, but these subinterfaces you keep mentioning in your windows box sound like multiple ethernet interfaces. This means that you just need to figure out which is which by assiging dummy addresses for purposes of identification until you are confident of which ones you are dealing with- then re-assign the ones you are going to be dealing with in production. Then, in Network connections, where you see all the icons for the different interfaces, you can f2 each one of them and rename them. After that when you run ipconfig (or ipconfig /all) from the command prompt you will see the labels for each interface. Do me a favor, post the results of your "ipconfig /all" in your next reply here and that will help to clear some confusion you have on what you are dealing with.

Running "netsh interface ipv4 show subinterfaces" gives me these two, and what I was worried about is I dont know the subinterface numbering of these....maybe subinterface #1 is the real one, or its that loopback one with gigantic MTU :s
Would be better to specify interface name or whatever when setting MTU, not subinterface number cause I cant even see it listed.