rebooting my cable modem: why?
-
Maximilien wrote:
maybe memory leak in the firmware ?
Yeah, I bet that is a good a guess as any. Well, someone should create a modem that never needs to be rebooted! Ok, I've given this Billion-dollar idea away, now someone please build it and sell it for $50. :laugh:
but can you also supply the codes?:cool:
-
Maximilien wrote:
maybe memory leak in the firmware ?
Yeah, I bet that is a good a guess as any. Well, someone should create a modem that never needs to be rebooted! Ok, I've given this Billion-dollar idea away, now someone please build it and sell it for $50. :laugh:
My first thought as well. Then: It is my honest opinion that firmware should not use dynamic allocation of memory at all. It has a well defined job to do; the memory requirements for all tasks should be possible to calculate in advance. That is, the code and data should be structured so that it is possible to calculate all memory needs in advance, and to set off that memory at compile time. There are reasons why Fortran (with no dynamic memory allocation, and for many versions without a stack - no recursion possible) held up for so long. One of the reasons was that is was reliable wrt. memory allocation: It would never crash due to a failing new() or a too deep recursion. Ada, made for military robustness, did allow recursion, but only if a static code analysis could calculate the deepest nesting level and stack requirement. CHILL, created for embedded code in telephone switches, required that you marked functions that are to be called recursively. I don't think it made any difference in generated machine code; it was just a way for the compiler to raise a red flag: Here you make a recursion to a function that is not marked as RECURSIVE. Look out - maybe you will run into stack issues. Embedded code is executed in an environment where you don't have the same facilities as for desktop applications. Often, less resources are available; you can't just let the stack grow to fill those 16 GBytes of RAM. So, the programmer cannot be allowed the same freedom as a standard application developer. Far more restrictive use of dynamic memory and stack are among the limitations an embedded developer should accept. I know well that this is certainly always reality in embedded code.
-
My first thought as well. Then: It is my honest opinion that firmware should not use dynamic allocation of memory at all. It has a well defined job to do; the memory requirements for all tasks should be possible to calculate in advance. That is, the code and data should be structured so that it is possible to calculate all memory needs in advance, and to set off that memory at compile time. There are reasons why Fortran (with no dynamic memory allocation, and for many versions without a stack - no recursion possible) held up for so long. One of the reasons was that is was reliable wrt. memory allocation: It would never crash due to a failing new() or a too deep recursion. Ada, made for military robustness, did allow recursion, but only if a static code analysis could calculate the deepest nesting level and stack requirement. CHILL, created for embedded code in telephone switches, required that you marked functions that are to be called recursively. I don't think it made any difference in generated machine code; it was just a way for the compiler to raise a red flag: Here you make a recursion to a function that is not marked as RECURSIVE. Look out - maybe you will run into stack issues. Embedded code is executed in an environment where you don't have the same facilities as for desktop applications. Often, less resources are available; you can't just let the stack grow to fill those 16 GBytes of RAM. So, the programmer cannot be allowed the same freedom as a standard application developer. Far more restrictive use of dynamic memory and stack are among the limitations an embedded developer should accept. I know well that this is certainly always reality in embedded code.
Great post. Those are some great points. and I guess the thing is that I have this piece of nifty hardware that feels like an FM radio receiver or something that just works all the time. You know what I mean...you never had to reboot your FM radio receiver. There were no chips that got full. It "just worked"! :D Anyways, I have this hardware that feels like hardware but it is actually software inside a brittle plastic box and it is, of course, the software that is broken. It's always software down at the bottom ruining everything. :laugh: Also, I know the FM radio receiver was analog and wasn't a computer and that's why it "just worked". Which makes me wonder...Instead of Quantum Computing maybe we should switch back to Analog Computers so they'll be dependable. ;P We don't need no stinking software! :rolleyes:
-
My first thought as well. Then: It is my honest opinion that firmware should not use dynamic allocation of memory at all. It has a well defined job to do; the memory requirements for all tasks should be possible to calculate in advance. That is, the code and data should be structured so that it is possible to calculate all memory needs in advance, and to set off that memory at compile time. There are reasons why Fortran (with no dynamic memory allocation, and for many versions without a stack - no recursion possible) held up for so long. One of the reasons was that is was reliable wrt. memory allocation: It would never crash due to a failing new() or a too deep recursion. Ada, made for military robustness, did allow recursion, but only if a static code analysis could calculate the deepest nesting level and stack requirement. CHILL, created for embedded code in telephone switches, required that you marked functions that are to be called recursively. I don't think it made any difference in generated machine code; it was just a way for the compiler to raise a red flag: Here you make a recursion to a function that is not marked as RECURSIVE. Look out - maybe you will run into stack issues. Embedded code is executed in an environment where you don't have the same facilities as for desktop applications. Often, less resources are available; you can't just let the stack grow to fill those 16 GBytes of RAM. So, the programmer cannot be allowed the same freedom as a standard application developer. Far more restrictive use of dynamic memory and stack are among the limitations an embedded developer should accept. I know well that this is certainly always reality in embedded code.
Allocating most memory during initialization, based on configuration parameters, is good practice in servers. I worked on telephone switches and never wrote anything recursive. But I did write some interesting code in which function #1 invoked function #2, which in turn invoked function #1. A former boss wrote the code for call waiting. When one of the calls needed something done on the other call, it sent a message. After several releases the code stumbled into an obscure path where the two calls just kept exchanging messages, creating an overload situation. Although there was code to guard against one call getting into an infinite loop, this hadn't been anticipated. When the code was fixed, defensive code was also added to guard against any one call using an unbecoming percentage of the CPU time.
Robust Services Core | Software Techniques for Lemmings | Articles
-
Invariably I have to reboot my cable modem. It is more rare than at the last place I lived -- we get much higher speeds here and it is more consistent. However, I still have to reboot sometimes. Will the Real Engineer, Please Standup? Please Standup! Can someone tell me why this helps? Do the bits get stuck in there and clog things up? 1. What are the real reasons that cycling power helps? 2. If that helps, why don't they have a button that lets just the specific firmware be rebooted? (kind of ridiculous question, but it'd be nice.) Ok, now I'll just sit back and wait for the answers to start pouring in. :rolleyes:
-
Good question. Most routers are based on Linux. The Linux weenies claim Linux gets great uptime. So why do some routers need to be rebooted more often than I have to reboot my Windows machine (of all things)...?
dandy72 wrote:
Most routers are based on Linux. The Linux weenies claim Linux gets great uptime.
:thumbsup: Very good point. I run Ubuntu on my home rig and haven't booted into Windows for a couple of weeks now either -- since WFH. But, you are right...it may be Linux's fault down at the bottom. I'll have to see if I can tell what my generic cable modem (from Spectrum) runs.
-
maybe memory leak in the firmware ?
I'd rather be phishing!
-
The wires get too hot. :D I have considered putting mine on a timer so it is powered off from midnight to dawn or so.
-
Invariably I have to reboot my cable modem. It is more rare than at the last place I lived -- we get much higher speeds here and it is more consistent. However, I still have to reboot sometimes. Will the Real Engineer, Please Standup? Please Standup! Can someone tell me why this helps? Do the bits get stuck in there and clog things up? 1. What are the real reasons that cycling power helps? 2. If that helps, why don't they have a button that lets just the specific firmware be rebooted? (kind of ridiculous question, but it'd be nice.) Ok, now I'll just sit back and wait for the answers to start pouring in. :rolleyes:
-
Invariably I have to reboot my cable modem. It is more rare than at the last place I lived -- we get much higher speeds here and it is more consistent. However, I still have to reboot sometimes. Will the Real Engineer, Please Standup? Please Standup! Can someone tell me why this helps? Do the bits get stuck in there and clog things up? 1. What are the real reasons that cycling power helps? 2. If that helps, why don't they have a button that lets just the specific firmware be rebooted? (kind of ridiculous question, but it'd be nice.) Ok, now I'll just sit back and wait for the answers to start pouring in. :rolleyes:
Even if you allocate all memory in the initialization phase and even if you do not use any dynamic tricks - such as recursion, dynamic function calls or the like - there could still be a problem. If the programmer is a bit sloppy s/he could forget to initialize a variable (for example a pointer variable). If that variable is used only in certain situations that could cause a problem then. Another common situation is not to handle all exceptions. An given exception may be very rare and thus forgotten about, until that day of doom when a situation occurs that throws the exception. If that one is not handled or handled in the wrong way we also have a problem that will cause the state of the modem into unknown land. Suddenly a variable may have a new value that stopped parsing or whatever. Communication devices must be designed to deal with any kinds of interrupts at all time. It is complicated to test if the software is stable under all circumstances and the cheaper the device is, the lesser time to test is give the developer. So, lack of testing could also be a problem. It all leads up to the situation:
1 In the beginning - all is fine
2 In due cause something happens
3 That something changes the state of the modem into uncertainty
4 Now the modem is behaving "strange"
5 So: Reboot it and go back to 1.That is my take on why you should reboot your hardware from time to time...
-
Even if you allocate all memory in the initialization phase and even if you do not use any dynamic tricks - such as recursion, dynamic function calls or the like - there could still be a problem. If the programmer is a bit sloppy s/he could forget to initialize a variable (for example a pointer variable). If that variable is used only in certain situations that could cause a problem then. Another common situation is not to handle all exceptions. An given exception may be very rare and thus forgotten about, until that day of doom when a situation occurs that throws the exception. If that one is not handled or handled in the wrong way we also have a problem that will cause the state of the modem into unknown land. Suddenly a variable may have a new value that stopped parsing or whatever. Communication devices must be designed to deal with any kinds of interrupts at all time. It is complicated to test if the software is stable under all circumstances and the cheaper the device is, the lesser time to test is give the developer. So, lack of testing could also be a problem. It all leads up to the situation:
1 In the beginning - all is fine
2 In due cause something happens
3 That something changes the state of the modem into uncertainty
4 Now the modem is behaving "strange"
5 So: Reboot it and go back to 1.That is my take on why you should reboot your hardware from time to time...
I was told that the best reason to regularly reboot your router is that when glitches happen, the modem negotiates to find a slower speed that would work, but it never tries to negotiate for a faster speed. So as time goes by and glitches occur, it's going slower and slower until you reset it by rebooting it. Either way, I'm finding weekly reboots are becoming necessary for my router. I should test it to see if a simple software reboot fixes it, or if it truly needs the power off/wait 30 seconds/power on process we've been doing, since I could do the software reboot from anywhere on the wifi, without a trip to the basement.
-
Great post. Those are some great points. and I guess the thing is that I have this piece of nifty hardware that feels like an FM radio receiver or something that just works all the time. You know what I mean...you never had to reboot your FM radio receiver. There were no chips that got full. It "just worked"! :D Anyways, I have this hardware that feels like hardware but it is actually software inside a brittle plastic box and it is, of course, the software that is broken. It's always software down at the bottom ruining everything. :laugh: Also, I know the FM radio receiver was analog and wasn't a computer and that's why it "just worked". Which makes me wonder...Instead of Quantum Computing maybe we should switch back to Analog Computers so they'll be dependable. ;P We don't need no stinking software! :rolleyes:
I'm glad I'm not the only analog electronic fan (in some areas) For example I'm fed up with digital switches that keep draining batteries even when you switch off (Hey Sony A7 or Thinkpad8, can you hear me?) or refuse to power on when you switch on and you have to hold the switch down for 1 minute đĄ And then do you want to compare the pleasure and comfort to feel with your fingers a phisical switch you can operate even in the dark vs a touch one? How about the pleasure to fine tune FM radio with an analog tuning wheel vs a beeping digital RDS scanner deciding instead of you which tunes are ok to play and which ones are to bypass? An analog volume amp vs a digital one? The 1st analog walkman and its headphones vs the new digital players with earbuds? The 80s analog HiFi systems vs the current digital micro HiFi? Am i the only analog nostalgic? Please bring back some old school analog devices đ even at premium price I'd buy some
-
I'm glad I'm not the only analog electronic fan (in some areas) For example I'm fed up with digital switches that keep draining batteries even when you switch off (Hey Sony A7 or Thinkpad8, can you hear me?) or refuse to power on when you switch on and you have to hold the switch down for 1 minute đĄ And then do you want to compare the pleasure and comfort to feel with your fingers a phisical switch you can operate even in the dark vs a touch one? How about the pleasure to fine tune FM radio with an analog tuning wheel vs a beeping digital RDS scanner deciding instead of you which tunes are ok to play and which ones are to bypass? An analog volume amp vs a digital one? The 1st analog walkman and its headphones vs the new digital players with earbuds? The 80s analog HiFi systems vs the current digital micro HiFi? Am i the only analog nostalgic? Please bring back some old school analog devices đ even at premium price I'd buy some
buttons never had this problem. However, actually - after getting a 1/2 decent car-stereo, I wouldn't buy an analog unit if they were free. The DSP and the included impulse responses can make poorly positioned speakers magically sound like they've moved from calf-height to shoulder height. I could never wrap my head around that before looking at convolution, fast fourier transform and a bunch of other software tricks. Tricks unavailable without a cpu. -
Good question. Most routers are based on Linux. The Linux weenies claim Linux gets great uptime. So why do some routers need to be rebooted more often than I have to reboot my Windows machine (of all things)...?
How did you get Windows to stop rebooting for updates?
-
Invariably I have to reboot my cable modem. It is more rare than at the last place I lived -- we get much higher speeds here and it is more consistent. However, I still have to reboot sometimes. Will the Real Engineer, Please Standup? Please Standup! Can someone tell me why this helps? Do the bits get stuck in there and clog things up? 1. What are the real reasons that cycling power helps? 2. If that helps, why don't they have a button that lets just the specific firmware be rebooted? (kind of ridiculous question, but it'd be nice.) Ok, now I'll just sit back and wait for the answers to start pouring in. :rolleyes:
I kinda like the sentiment from stilldrinking.org
Not a single living person knows how everything in your five-year-old MacBook actually works. Why do we tell you to turn it off and on again? Because we donât have the slightest clue whatâs wrong with it, and itâs really easy to induce coma in computers and have their built-in team of automatic doctors try to figure it out for us. The only reason codersâ computers work better than non-codersâ computers is coders know computers are schizophrenic little children with auto-immune diseases and we donât beat them when theyâre bad.
-
I kinda like the sentiment from stilldrinking.org
Not a single living person knows how everything in your five-year-old MacBook actually works. Why do we tell you to turn it off and on again? Because we donât have the slightest clue whatâs wrong with it, and itâs really easy to induce coma in computers and have their built-in team of automatic doctors try to figure it out for us. The only reason codersâ computers work better than non-codersâ computers is coders know computers are schizophrenic little children with auto-immune diseases and we donât beat them when theyâre bad.
ha ha ha... Genius. I can however.. possibly shed some light on this. Ok, first thing you have to remember is that all modems (Adsl, Vdsl, whatever) [static or dynamically addressed] are allocated their slot in the switching system using DHCP and similar technologies. If your on a cheap as chips consumer connection then there's a dead cert that your dynamically addressed, and... on dynamically addressed connections your ISP simply does not ever allocate enough IP leases in their DHCP pool for every individual customer to have one. None of them do.... Why? Because IP leases that sit unused are expensive. What they do instead, is they allocate just enough to meet average peak demand on a daily basis, and that usually works well, simply because not everyone is trying to connect all the time. With many cable modems for example they connect on demand, so if everyone in the household is sleeping, all the computers and phones are off, and nothing is using the connection, the modem will typically release it's lease for someone else to use, and re-request a new one as soon as the first bit of data for the day goes through it. As I say, this generally works well, as lot's of devices go off as others come online and the amount in the lease pool has enough allocations. Some ISP's however get it very wrong, or flat out don't care as long as they get to spend only what they want to spend to provide a service, couple that with times of network stress when there is more than the normal average using the system, and more people staying online longer, it means that very quickly the lease pool dries up. Some ISP's can and do dynamically expand the lease pools to meet demand, many don't because it's all about the $$$ at the end of the day. Many modems and other devices also have "forced lease" renewals, so for EG: you connect on a morning, you get a 12h lease, the world goes crazy, every one log's on, 12 hours later whether you like it or not, your modem is forced to re-lease it's connection and boom.... no free slots in the pool. A lot of consumer modems are made in china as cheaply as possible, so even though they might run linux, things like buffer chips and octal drivers are done with as cheap a chip cost as possible, you might only have a couple of K of buffer memory, or the octal line drivers might have a 3ms latch time on them instead of a 1ms latch time. What you end up with is a device who's hardware performs very, very poorly when it's auto connection starts hammering the ISP line to t
-
Invariably I have to reboot my cable modem. It is more rare than at the last place I lived -- we get much higher speeds here and it is more consistent. However, I still have to reboot sometimes. Will the Real Engineer, Please Standup? Please Standup! Can someone tell me why this helps? Do the bits get stuck in there and clog things up? 1. What are the real reasons that cycling power helps? 2. If that helps, why don't they have a button that lets just the specific firmware be rebooted? (kind of ridiculous question, but it'd be nice.) Ok, now I'll just sit back and wait for the answers to start pouring in. :rolleyes:
-
How did you get Windows to stop rebooting for updates?
Where did I say that? The closest approximation to what you're claiming I said is that there are routers that have to be rebooted more frequently than some of my Windows systems (or words to that effect--they're still there for you to go back to and re-read).
-
Even if you allocate all memory in the initialization phase and even if you do not use any dynamic tricks - such as recursion, dynamic function calls or the like - there could still be a problem. If the programmer is a bit sloppy s/he could forget to initialize a variable (for example a pointer variable). If that variable is used only in certain situations that could cause a problem then. Another common situation is not to handle all exceptions. An given exception may be very rare and thus forgotten about, until that day of doom when a situation occurs that throws the exception. If that one is not handled or handled in the wrong way we also have a problem that will cause the state of the modem into unknown land. Suddenly a variable may have a new value that stopped parsing or whatever. Communication devices must be designed to deal with any kinds of interrupts at all time. It is complicated to test if the software is stable under all circumstances and the cheaper the device is, the lesser time to test is give the developer. So, lack of testing could also be a problem. It all leads up to the situation:
1 In the beginning - all is fine
2 In due cause something happens
3 That something changes the state of the modem into uncertainty
4 Now the modem is behaving "strange"
5 So: Reboot it and go back to 1.That is my take on why you should reboot your hardware from time to time...
-
I was told that the best reason to regularly reboot your router is that when glitches happen, the modem negotiates to find a slower speed that would work, but it never tries to negotiate for a faster speed. So as time goes by and glitches occur, it's going slower and slower until you reset it by rebooting it. Either way, I'm finding weekly reboots are becoming necessary for my router. I should test it to see if a simple software reboot fixes it, or if it truly needs the power off/wait 30 seconds/power on process we've been doing, since I could do the software reboot from anywhere on the wifi, without a trip to the basement.
RDM Jr wrote:
was told that the best reason to regularly reboot your router is that when glitches happen, the modem negotiates to find a slower speed that would work, but it never tries to negotiate for a faster speed. So as time goes by and glitches occur, it's going slower and slower until you reset it by rebooting it.
:thumbsup: That is a very interesting point and seems to match the experience.
