On Windows machines hard drives automatically sleep and spin down when they are not in use. This theoretically extends the life of your USB or SATA hard drive. On Linux systems you often have to configure power saving parameters for your hard drive manually. For the little Raspberry Pi and its.
I use 'wheezy' latest release. The device provides some web service features and supposes to be active 24/7. However if the server wasn't requested for certain amount of time (it is hard to tell exact time), the device seems going to sleep (hopefully not crash). The device connected to net using wi-fi dongle. I found some answers here that a reason of device freezing can be that wi-fi card is going in economy mode, so I followed the instructions and can confirm that the dongle doesn't go in sleep but it starts blinking like getting not attended from computer.
It means that device still goes in sleep although wi-fi is awake. The solution as buy another raspberry pi and make it all time pinging sleeping one doesn't work since only being a server getting requests prevent device going to sleep. Trying to poll something from the device doesn't prevent going in sleep mode.
I can't actually confirm that device going to sleep. I do not have monitor or keyboard attached, and attempt to attach something issues rebooting of the device.
So I am currently out of clues what can issue the behavior. And yes, I applied all remedies preventing OS crashes as no turbo and increased minimal VM memory size. I have had this problem of the Pi apparently going to sleep. I can happen every few minutes and can last for about 20 seconds. It is evident when I am trying to access a file via Samba share or when I am SSHing into the Pi - everything just stops. I thought that it might be the Pi that was under load so I ran 'top'.
There was no evidence of heavy loading. However, I found that while running 'top', the Pi worked perfectly.
Access to files was snappy and SSH connections experienced no outage. So, I can't say what causes this problem but it is not heavy demands on the CPU, on the contrary, the Pi–Feb 22 '14 at 20:37. Something is wrong. The pi does not have a 'sleep mode'.I've only had my pi a few weeks and have not left it on the whole time, but I intend to eventually and I have left it on for some long stretches. I'm running raspbian, and I have a personal dislike for NetworkManager, lol, so that is disabled. To keep the wifi up, I run a script which pings the router every five seconds. If the ping fails, it kills the current dhcpcd and tries to set up the wifi again every 5 seconds until it succeeds.
It logs attempts, and in fact has been up for over 24 hours now without needing to reconnect once, and when I go to ssh in, no problems.You've already said,'Trying to poll something from the device doesn't prevent going in sleep mode,' so my point here is just that mine obviously doesn't have this problem, so something is wrong.You say it is going 'to sleep' but it sounds like you are actually having to reboot. Why do you believe it is sleeping? AFAICT, the pi cannot go to sleep, it does not have any such capability.
Googling around, there seems to be some confusion about this from people who are having problems like yours.Keep in mind that there is a red LED that stays on whenever power is connected, whether the pi is running or not. But the pi is either booted and running or halted,.So your pi has either crashed, halted, or is in some kind of erroneous frozen state. Feel to see if it is more than slightly warm, which would indicate the processor is in a perpetual busy loop (one reason it might be on but unresponsive).I'm guessing that one reason you believe it is sleeping is that an 'attempt to attach something issues rebooting of the device'.
That can happen when the device is completely halted (try it); it's because some devices will cause (but see NOTE) when first plugged in, which amounts to unplugging the pi then plugging it back in again - which as you know, plugging it in causes it to boot. My nano size wifi dongle will do this.NOTE: Actually our pi were probably made since last august, when the polyfuses were replaced with 'shorts' - I know very little about electronic components or electricity, but evidently the issue WRT to rebooting from usb devices. I know this is an old question, but it was the first result that came up in my search when I had essentially the same problem on my freshly installed Pi Zero.I found the key to my answer on, among other sources.So basically, though the Pi itself apparently doesn't have a sleep mode, individual devices in Linux (including the network adapters) can. When I tried running the command iw wlan0 get powersave as mentioned above, I kept getting an error, at first. That was fixed by updating the OS: sudo apt-get update && apt-get upgradeThen I rebooted: sudo reboot nowAfter that, the iw command verified that powersave mode was indeed turned on. So, I turned it off: sudo iw wlan0 set powersave offSince then, everything is fine.
My screen will go to sleep, but the network connection stays active, and I'm able to ssh into my Pi even after it's been idle for a while. I wonder if I am experiencing something similar. I would be interested in the chip set your dongle has and the driver you are using?I have one based on RT3072 chip using the rt2800usb / cfg80211 driver. If I run this in either Master Mode ie an Access Point, or as a normal client to an Access Point/router, it appears as if it goes to sleep and takes a while to respond. I set up my laptop to ping the pi through the wifi adapter at roughly 1 second intervals.
I confirmed that in both master and client mode, at times the ping would time out 5-10 seconds in client mode and 5 - 25 seconds in Master mode. In master mode, the timeouts were made a lot worse if I ran the AP in 'n mode' with HT and WMM enabled in hostapd.conf. It was no where near as bad in 'g mode'.I experimented with another wifi dongle using the RTL8188SU chip with r8712u staging driver. Unfortunately, I could not get this running in Master mode but as a client, it was much more stable than the RT3072 one.With the 3072 in client mode there was no typical ping delay - they were random from 2ms - 320ms with an occasional timeout. With 8188SU, the typical ping delay was 2-3ms with an occasional delay 166-200ms delay - no observable timeouts. What was particularly strange was that if I opened an ssh session to the pi and set top running at 0.01 sec - so there was quite a lot of cpu load and a 'lot' of wifi traffic, the performance of the 3072 was greatly improved with ping times typically 2-3ms. The loading had a similar effect on the 3072 working in Master mode.I don't know what is going on but I would be most interested if other users could take the time to do a similar ping test on their pi and report their findings along with their configuration and drivers.
It would be interesting if others find poor and random response times are improved by loading the processor/ wifi traffic using top as I did, or say find anything that creates some work and tcp/ip traffic over the wifi. I tried implementing Stefans answer - turning off power management (for cfg80211/mac80211 drivers you can use iw wlan0 set powersave off), and it made a very big difference in the client mode - random ping delays are now fairly steady at 2-3ms and no timeouts yet. This has not helped with the AP mode (powersave off is not an option with my device), but I don't think it is the source of the problem in AP mode as the ping times are generally stable anyway. Something else is causing the timeouts. It is not clear whether the configuration in the original question was for client or AP mode.–Feb 14 '13 at 4:42.
Without installing anything, official Raspberry Pi doc:On the ConsoleIf you are using the Raspberry Pi solely on the console (no desktop GUI), you need to set the console blanking. The current setting, in seconds, can be displayed usingcat /sys/module/kernel/parameters/consoleblankHere, consoleblank is a kernel parameter. In order to be permanently set, it needs to be defined on the kernel command line.sudo nano /boot/cmdline.txtAdd consoleblank=0 to turn screen blanking off completely, or edit it to set the number of seconds of inactivity before the console will blank. Note the kernel command line must be a single line of text.