Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › Network mounts broke after resume from sleep...
New Posts  All Forums:Forum Nav:

Network mounts broke after resume from sleep... - Page 12  

post #111 of 120
Quote:
Originally Posted by CaptainBlame View Post

For the record, I mounted an nfs share on my wireless OpenBSD laptop, played a video located on the share, sleep the laptop while the video is still playing, and resumed it and video continued with no hiccup. Suspend is instant, resume takes max 2 seconds. Will try Ubuntu next.

That sounds an awful lot like OpenBSD isn't suspending your NIC properly and/or its using obscenely large player buffers, which would be terrible if you wanted real time performance.

Either way, OpenBSD if failing bad, you're falling bad and the only good thing to come outof this is evidence that you don't really know the slightest thing about what you're doing just so long as the OS appears to be working from a surface view.
post #112 of 120
Quote:
Originally Posted by Plan9 View Post

That sounds an awful lot like OpenBSD isn't suspending your NIC properly and/or its using obscenely large player buffers, which would be terrible if you wanted real time performance.

Either way, OpenBSD if failing bad, you're falling bad and the only good thing to come outof this is evidence that you don't really know the slightest thing about what you're doing just so long as the OS appears to be working from a surface view.

How do you figure that? I can see the wireless NIC being reinitialized when i resume. The OpenBSD developers had a big focus on suspend/resume a few releases ago, from my observation its on par or better than OSX/macbooks when using Thinkpads.


The video only resumes after the wireless initializes. I doubt it's huge buffers, plus the laptop is a $100 Thinkpad x200 streaming via nfs from a 5 watt server, 500mhz, with 256 mb ram (which runs sickbeard, imap and apache in the background too). Real time performance looks fine to me lol.
Edited by CaptainBlame - 3/27/14 at 2:44am
post #113 of 120
Quote:
Originally Posted by CaptainBlame View Post

How do you figure that? I can see the wireless NIC being reinitialized when i resume. The OpenBSD developers had a big focus on suspend/resume a few releases ago, from my observation its on par or better than OSX/macbooks when using Thinkpads.

Because it takes about 60 seconds (hugely approximated figure) for a wireless NIC to negotiate an IP.

Also OS X doesn't follow the spec for renegotiating handshakes (it makes a number of assumptions based on the previous state - which is dangerous if other devices have come online since); and given the security focus of OpenBSD, I'd rather it follow protocol correctly than fudge shortcuts to trick pseudo-techies into thinking their OS performs better than competing platforms.

Honestly, the more you harp on about this subject, the worse you and OpenBSD are coming off.
Edited by Plan9 - 3/27/14 at 2:43am
post #114 of 120
Thread Starter 
Quote:
Originally Posted by Plan9 View Post

Because it takes about 60 seconds (hugely approximated figure) for a wireless NIC to negotiate an IP.

Also OS X doesn't follow the spec for renegotiating handshakes (it makes a number of assumptions based on the previous state - which is dangerous if other devices have come online since); and given the security focus of OpenBSD, I'd rather it follow protocol correctly than fudge shortcuts to trick pseudo-techies into thinking their OS performs better than competing platforms.

I wouldn't say 60 seconds (I get it was approximate). It takes much less but its not instant for sure.

Heh Apple are very notorious for not following DHCP spec. I remember there was something funky they were doing on iOS to make IP negotiation faster but I can't find it now...
Ol' Sandy
(28 items)
 
"Zeus"
(12 items)
 
Elite Preview
(6 items)
 
CPUMotherboardGraphicsRAM
Intel Xeon E3-1230v3 Gigabyte GA-Z97X-UD5H-BK MSI Gaming GTX 980 Kingston 32GB (4x8) 
Hard DriveHard DriveHard DriveHard Drive
Plextor PX-256M5S 256GB Samsung EVO 1TB Hitachi HDS721010CLA332 Hitachi HDS723020BLA642 
Hard DriveHard DriveHard DriveOptical Drive
Hitachi HDS723020BLA642 Hitachi HUA722010CLA330 WDC WD10EARS-00Z5B1 TSSTcorp CDDVDW SH-S223B 
CoolingCoolingOSMonitor
Phanteks PH-TC14PE with TY-140's Lamptron FCv5 (x2) Windows 8 Pro 64-bit Dell U2412M 
MonitorMonitorMonitorKeyboard
Dell U2412M Dell U2212HM Dell U2713HM Topre Realforce 87UB | Ducky DK9087 G2 Pro 
PowerCaseMouseMouse Pad
Corsair AX-750 Corsair Obsidian 650D Logitech G700 XTRAC Ripper XXL 
AudioAudioAudioAudio
Beyerdynamic DT-770 Pro 250ohm Schiit Bifrost DAC Schiit Asgard 2 HiVi Swan M50W 2.1 
CPUMotherboardRAMHard Drive
Intel Xeon E5-2620 Super Micro X9SRL-F-B 128GB 1333MHz LSI 9271-8i 
OSPowerCase
VMware ESXi 5.5 SeaSonic SS-400FL2 Fractal Define R3 
CPUMotherboardGraphicsRAM
Intel Core i5-3437U HP EliteBook Folio 9470m  Intel HD Graphics 4000  16GB DDR3 SDRAM 
Hard DriveOS
256GB SSD Windows 10 Insider Preview 
  hide details  
Ol' Sandy
(28 items)
 
"Zeus"
(12 items)
 
Elite Preview
(6 items)
 
CPUMotherboardGraphicsRAM
Intel Xeon E3-1230v3 Gigabyte GA-Z97X-UD5H-BK MSI Gaming GTX 980 Kingston 32GB (4x8) 
Hard DriveHard DriveHard DriveHard Drive
Plextor PX-256M5S 256GB Samsung EVO 1TB Hitachi HDS721010CLA332 Hitachi HDS723020BLA642 
Hard DriveHard DriveHard DriveOptical Drive
Hitachi HDS723020BLA642 Hitachi HUA722010CLA330 WDC WD10EARS-00Z5B1 TSSTcorp CDDVDW SH-S223B 
CoolingCoolingOSMonitor
Phanteks PH-TC14PE with TY-140's Lamptron FCv5 (x2) Windows 8 Pro 64-bit Dell U2412M 
MonitorMonitorMonitorKeyboard
Dell U2412M Dell U2212HM Dell U2713HM Topre Realforce 87UB | Ducky DK9087 G2 Pro 
PowerCaseMouseMouse Pad
Corsair AX-750 Corsair Obsidian 650D Logitech G700 XTRAC Ripper XXL 
AudioAudioAudioAudio
Beyerdynamic DT-770 Pro 250ohm Schiit Bifrost DAC Schiit Asgard 2 HiVi Swan M50W 2.1 
CPUMotherboardRAMHard Drive
Intel Xeon E5-2620 Super Micro X9SRL-F-B 128GB 1333MHz LSI 9271-8i 
OSPowerCase
VMware ESXi 5.5 SeaSonic SS-400FL2 Fractal Define R3 
CPUMotherboardGraphicsRAM
Intel Core i5-3437U HP EliteBook Folio 9470m  Intel HD Graphics 4000  16GB DDR3 SDRAM 
Hard DriveOS
256GB SSD Windows 10 Insider Preview 
  hide details  
post #115 of 120
Quote:
Originally Posted by Plan9 View Post

Because it takes about 60 seconds (hugely approximated figure) for a wireless NIC to negotiate an IP.

Also OS X doesn't follow the spec for renegotiating handshakes (it makes a number of assumptions based on the previous state - which is dangerous if other devices have come online since); and given the security focus of OpenBSD, I'd rather it follow protocol correctly than fudge shortcuts to trick pseudo-techies into thinking their OS performs better than competing platforms.

Honestly, the more you harp on about this subject, the worse you and OpenBSD are coming off.

Cool theory, to humor you trying to discredit OpenBSD approach to correctness and security which they take more serious than any other. I reran the test, this time while the system was suspended, I deleted its dhcp reservation from my router and assigned it a new reservation with a different IP. It resumed playing the movie same as before with the new IP address, no delay etc.
post #116 of 120
Quote:
Originally Posted by CaptainBlame View Post

Cool theory, to humor you trying to discredit OpenBSD approach to correctness and security which they take more serious than any other.
I wasn't trying to discredit OpenBSD. I was just highlighting how absurd you always sound.
post #117 of 120
So does this mean you are satisfied with the DHCP renegotiation, cause I'll include that scenario in Ubuntu's test.
post #118 of 120
Quote:
Originally Posted by CaptainBlame View Post

So does this mean you are satisfied with the DHCP renegotiation, cause I'll include that scenario in Ubuntu's test.

It means I couldn't care less.

Network shares work fine for me and I genuinely have no interest in proving they do to a fanboy who equally couldn't care less about anything other than his own prejudices.
post #119 of 120
It appears that systemd is getting a fast dhcp server/client, so it looks like Linux too will be cheating the dhcp negotiation. So hard to find a good honest OS these days.

http://www.phoronix.com/scan.php?page=news_item&px=MTY1Mjc
post #120 of 120
Locked as per request
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Linux, Unix
This thread is locked  
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › Network mounts broke after resume from sleep...