When I typed

 

ifconfig eth0 mtu 9014 up at the command prompt, I got a SIOCSIFMTU: Invalid argument.  What does that mean?

 

I read in the topic below that the driver for Asus P5B-VM DO does not support jumbo frame, is this the same with my board as well?  I chose this board because it was compatible and I skipped other boards that have better features due to the fact this board has onboard gige lan.  But I did not realize that the onboard lan might not support jumbo frame.  This is quite disappointing is that's the case.  Now I gotta shell out another $45 for a Intel 1000Pro...

I feel the same way. I assumed that the recommended board would be the most complete. In Sweden at least, this board isn't all that cheap (US 140).

This may simply be a case of a product missing a feature that is unnecessary anyway.

 

I do not believe jumbo frames is/are terribly productive for Unraid.  Feel free to step in and prove me wrong with some actual testing as I would love to squeeze a bit more performance out of the box.

 

 

Bill

You are correct Bill.

 

Assuming we are in an environment of transferring large media files (typcial unRAID application), jumbo frames can help where you have high latency or are experiencing collisions. 

 

Latency is usually not an issue on a home network.  Plus burst mode has a greater impact on latency problems.  Since 1GB topology is switched, collisions are not an issue.  The store and forward nature of the switch will add to latency, but it prevents prorogation of errors.

 

On a 1GB wire, in a collision-detection domain, generally the best you can hope for is 40% of wirespeed, with 20% of wirespeed more typical.  So 25 MBytes/sec to 50 MBytes/sec is the expected performance you can get from a 1GB ethernet wire under good conditions.  Unless you have a disk that can significantly exceed that, jumbo frames won't help much.

 

Now if your disk can meet that throughput, but your network speed is significantly lower, then you should try new cables, a different switch, and different NICs on both ends.

 

 

Actually, the main question is still unanswered.  Does M2NPV-VM's onboard lan support jumbo frame?

 

I have 2 XP boxes on gige, and when I enabled jumbo frame, I did see an improvement.  One of the box has a slow drive, but the improvement is still almost doubled what I was seeing with mtu at 1500.  I'd say doubling the speed is quite significant.

Actually, the main question is still unanswered.  Does M2NPV-VM's onboard lan support jumbo frame?

 

I have 2 XP boxes on gige, and when I enabled jumbo frame, I did see an improvement.  One of the box has a slow drive, but the improvement is still almost doubled what I was seeing with mtu at 1500.  I'd say doubling the speed is quite significant.

Checking the manual at Asus, it doesn't specifically say Jumbo frames are supported, which should mean they are not supported.

 

Also, I was not referring to the general benefit of Jumbo frames, I was talking about Jumbo frames with Unraid in the more common uses (i.e. serving audio/video files in a home network).  Have you tried this and found they are beneficial?

 

 

Bill

I did some Googling and it appears that the nForce 430 based boards like yours do NOT support frame sizes greater than 1500.  Those who tried got the exact error you received.  BTW there are many jumbo frame sizes, with 9000 and 9216 being much more commonly used than 9014.

 

Actually, the main question is still unanswered.  Does M2NPV-VM's onboard lan support jumbo frame?

 

I have 2 XP boxes on gige, and when I enabled jumbo frame, I did see an improvement.  One of the box has a slow drive, but the improvement is still almost doubled what I was seeing with mtu at 1500.  I'd say doubling the speed is quite significant.

Checking the manual at Asus, it doesn't specifically say Jumbo frames are supported, which should mean they are not supported.

 

Also, I was not referring to the general benefit of Jumbo frames, I was talking about Jumbo frames with Unraid in the more common uses (i.e. serving audio/video files in a home network).  Have you tried this and found they are beneficial?

 

 

Bill

 

I have a rather short experience with jumbo at the moment.  But from what I can tell, it has been beneficial between my 2 windows boxes.  As for unRAID, I won't know unless I can get it working.  Get it working meaning perhaps a new nic.

I did some Googling and it appears that the nForce 430 based boards like yours do NOT support frame sizes greater than 1500.  Those who tried got the exact error you received.  BTW there are many jumbo frame sizes, with 9000 and 9216 being much more commonly used than 9014.

 

 

That just sucks.  Wish the hardware compatibility list would have more info.  I might end up returning this mobo altogether.  What board would satisfy all my requirements?

 

Socket AM2, 2 PCI at least with or without SATA.  Onboard video and lan with gige AND jumbo frame.  Also, if I swap motherboard, how would that affect the data I already moved over to the array?  If I leave the flash drive alone, would it pick right back up where it left off on a new motherboard?  Assuming of course I can get it boot up and mount the flash properly.

 

There should be a mobo that is the holy grail in the list.  Makes things a whole lot easier.  Probably make the sale of unRAID faster too.  I'm holding off my purchase untl I can finalize my hardware setup.  I can start with M2NPV-VM.  Socket AM2, 2 PCI, 2 PATA, 4 SATA, onboard video, gige ethernet, no jumbo frame.

 

ps. I used 9014 because my xp box would only has 9014 in the drop down.

There's been very little experimentation so far with jumbo frames, and with little success.  See this thread:  http://lime-technology.com/forum/index.php?topic=27

 

Also this wishlist by Tom mentions them (search: jumbo):  http://lime-technology.com/forum/index.php?topic=266.msg1861#msg1861

 

Also, if I swap motherboard, how would that affect the data I already moved over to the array?  If I leave the flash drive alone, would it pick right back up where it left off on a new motherboard?  Assuming of course I can get it boot up and mount the flash properly.

I and others had relatively little difficulty moving to new hardware.  Just note or print the drive serial #'s with their Disk #'s, and re-assign them when you boot the new board.

 

A new feature I've wanted to recommend to Tom is to do away with the /boot/config/disk.cfg file, and build it on the fly at boot time, using the info already in the superblock.dat.  The superblock contains the serial and disk number info that we write down for re-assignment, but not the hardware-specific info that disk.cfg has, and that can be determined by unRAID at boot, matching serial number with hardware slot and Disk number.  This would allow even more hardware independence, and even easier migrations such as yours, with no drive re-assignment necessary.  This would be another marketing feature for unRAID, compared to the alternatives.  This could allow you to carry a set of drives and the flash on the road, attach them to anyone's computer, and boot your unRAID.  [sounds too simple, so I apologize if I've forgotten something important.]

 

I did some Googling and it appears that the nForce 430 based boards like yours do NOT support frame sizes greater than 1500.  Those who tried got the exact error you received.  BTW there are many jumbo frame sizes, with 9000 and 9216 being much more commonly used than 9014.

 

 

That just sucks.  Wish the hardware compatibility list would have more info.  I might end up returning this mobo altogether.  What board would satisfy all my requirements?

 

Socket AM2, 2 PCI at least with or without SATA.  Onboard video and lan with gige AND jumbo frame.  Also, if I swap motherboard, how would that affect the data I already moved over to the array?  If I leave the flash drive alone, would it pick right back up where it left off on a new motherboard?  Assuming of course I can get it boot up and mount the flash properly.

 

There should be a mobo that is the holy grail in the list.  Makes things a whole lot easier.  Probably make the sale of unRAID faster too.  I'm holding off my purchase untl I can finalize my hardware setup.  I can start with M2NPV-VM.  Socket AM2, 2 PCI, 2 PATA, 4 SATA, onboard video, gige ethernet, no jumbo frame.

 

ps. I used 9014 because my xp box would only has 9014 in the drop down.

 

Many of us can empathize with your frustration, but keep in mind that "compatible" and "meets your individual requirements" are not synonymous.  Jumbo frames are not required by Unraid and are not needed to obtain sufficient performance to crank out as many video/audio streams as the vast majority of folks would want/need.

 

Yeah, I wish the compatibility list would include PCI vs. PCI-E, power use, cost, ....  Of course, since the wiki is a community-based compendium, perhaps this is your chance to add value to the list: go through the list of mobos/GigE and add "jumbo - yes" or "jumbo - no" to each.

 

BTW, buying a separate GigE card w/Jumbo frames would not only be easier than uninstalling/reinstalling your entire build, but you will likely end up with a better GigE implementation anyway.  For me, that would be worth the ~$25.

 

 

Bill

There's been very little experimentation so far with jumbo frames, and with little success.  See this thread:  http://lime-technology.com/forum/index.php?topic=27

 

If jumbo frame isn't really beneficial witn unRAID, does gige at least speed things up a little?

 

 

Also this wishlist by Tom mentions them (search: jumbo):  http://lime-technology.com/forum/index.php?topic=266.msg1861#msg1861

 

Also, if I swap motherboard, how would that affect the data I already moved over to the array?  If I leave the flash drive alone, would it pick right back up where it left off on a new motherboard?  Assuming of course I can get it boot up and mount the flash properly.

I and others had relatively little difficulty moving to new hardware.  Just note or print the drive serial #'s with their Disk #'s, and re-assign them when you boot the new board.

 

A new feature I've wanted to recommend to Tom is to do away with the /boot/config/disk.cfg file, and build it on the fly at boot time, using the info already in the superblock.dat.  The superblock contains the serial and disk number info that we write down for re-assignment, but not the hardware-specific info that disk.cfg has, and that can be determined by unRAID at boot, matching serial number with hardware slot and Disk number.  This would allow even more hardware independence, and even easier migrations such as yours, with no drive re-assignment necessary.  This would be another marketing feature for unRAID, compared to the alternatives.  This could allow you to carry a set of drives and the flash on the road, attach them to anyone's computer, and boot your unRAID.  [sounds too simple, so I apologize if I've forgotten something important.]

 

 

Thanks for the links, I actually went over both of them.  So as long as I keep superblock.dat, my data would be safe?  While I was troubleshooting my non-booting box this week, I formatted the usb drive and started anew(no superblock.dat).  To my surprise, unRAID needed to do parity clear on the parity drive again.  I thought it would have recognized that it has done it before this.  I had only added disk1 and no data were transferred to disk1 prior to my formatting the usb drive.  This scares me, I don't want to move the mobo then have unRAID start parity writing my disk.  (I do have the serials written down)

 

This forum rocks.  Lots of support and help.  Thanks guys.

My performance moving from 100Mb to GigE roughly doubled, so yes, there is a benefit.

 

I was hoping to get more like a 4X result and will continue to poke and pry at each component and each configuration element.

 

 

Bill

My performance moving from 100Mb to GigE roughly doubled, so yes, there is a benefit.

 

I was hoping to get more like a 4X result and will continue to poke and pry at each component and each configuration element.

 

 

Bill

 

Thanks for confirming that.  I suppose I can just wait and see if there will be any sort of improvement with jumbo frame.  If turns out there is (or code changes that benefits from jumbo) improvement, I can then order an Intel PRO/1000.

I've made my contribution.  I expanded the gige lan column with jumbo frame.  Then I added "no" to the M2NPV-VM's gige/jumbo frame column.

I've moved hardware without issue, I've even moved a disk fromone unRAID to another and maintained the data. Writing parity out doesn't harm data unless you designate the data disk AS the parity disk. It will not startup and do this on it's own. I've found that the easiest way to keep trck of disks etc. is to simply goto the devices page while the system is running and print out the page, remembering what goes where later is easy if you have it printed in front of you...

I've moved hardware without issue, I've even moved a disk fromone unRAID to another and maintained the data. Writing parity out doesn't harm data unless you designate the data disk AS the parity disk. It will not startup and do this on it's own. I've found that the easiest way to keep trck of disks etc. is to simply goto the devices page while the system is running and print out the page, remembering what goes where later is easy if you have it printed in front of you...

 

So a brand new unRAID flash drive will know what to do with the data disk if it seems data on it instead of just seeing it as unformatted etc.  Good to know.

I've moved hardware without issue, I've even moved a disk fromone unRAID to another and maintained the data. Writing parity out doesn't harm data unless you designate the data disk AS the parity disk. It will not startup and do this on it's own. I've found that the easiest way to keep trck of disks etc. is to simply goto the devices page while the system is running and print out the page, remembering what goes where later is easy if you have it printed in front of you...

 

So a brand new unRAID flash drive will know what to do with the data disk if it seems data on it instead of just seeing it as unformatted etc.  Good to know.

 

It didn't see the disk as unformatted however "knowing" what to do with it is a strong statement. It saw the drive and offered to update parity to reflect the new data set. I allowed that to occur and the data was available immedietly.

I've moved hardware without issue, I've even moved a disk fromone unRAID to another and maintained the data. Writing parity out doesn't harm data unless you designate the data disk AS the parity disk. It will not startup and do this on it's own. I've found that the easiest way to keep trck of disks etc. is to simply goto the devices page while the system is running and print out the page, remembering what goes where later is easy if you have it printed in front of you...

 

So a brand new unRAID flash drive will know what to do with the data disk if it seems data on it instead of just seeing it as unformatted etc.  Good to know.

 

It didn't see the disk as unformatted however "knowing" what to do with it is a strong statement. It saw the drive and offered to update parity to reflect the new data set. I allowed that to occur and the data was available immedietly.

 

I guess I simplified it too much.  Sounds like it won't see a new data drive with data as a "new" drive and think it's empty or needs formatting.  Which is a good thing.