|
|
|
What are the line stats at the locations?
That doesn't seem "crazy" to me. When you say the router crashes, you mean if you arrive you cannot browse the internet or access the router admin page right?
|
|
|
|
I mean they BOTH, on different random occasions, lock up, freeze, LED's on, not flickering, cannot access them wired or wireless.
Only thing to do is physically power them down then up (hence the time switches that cycle every night for when I cannot get to the router locations). Then they are fine for a random amount of time/days. could be hours, could be weeks. They are not getting hot. The cameras are fine and have not crashed. I also administer them remotely, but of course, not if they have crashed!
Router 1:
Connection Speed 8867 Kbps DWN 1146 Kbps UP
Line Attenuation 35.5 dB DWN 21.3 dB UP
Noise Margin 6.2 dB DWN 6.0 dB UP
Router 2:
Connection Speed 10326 Kbps DWN 1136 Kbps UP
Line Attenuation 26.6 dB DWN 15.1 dB UP
Noise Margin 12.3 dB DWN 5.9 dB UP
|
|
|
|
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
|
Martham
When the devices are working at the constant 1024Kbs upstream any other bits for any other purpose ( router synch etc) may exceed the upstream rate, over an indeterminate time this will overload the router and cause the freeze. The Upstream rate may be affected by line conditions over the course of a day and actually be below 1024Kbs, this may be atmospheric condition related or line related.
There may also be other network related things that slow the transmission down between the router and the distant server ( Including the server and it's immediate local network). This can also build up the effect over time.
Your daily reboot should normally overcome these issues but on odd days 24 hours may be enough to cause the issue.
Can you limit the stream to something under 1000Kbs. Otherwise a move to FTTC if possible with it's bigger upstream budget should cure the issue.
( Don't think you can get a bigger upstream with ADSL2+)
|
|
|
|
Upstream is very close to the max upstream of the webcams.
I would limit webcam upstream to 512Kbps if possible. It's likely the webcam is outputting higher than the connection speed, hence router runs out of ram and crashes...
Even a torrent user, it's unlikely to max out the connection for 24 solid hours on upstream, there's gaps where the demand is much lower.
Can you get a fibre optic service at these locations?
|
|
|
Also encoding systems while aiming for a capped maximum don't always hit that to the exact byte, i.e. the encoding of live material can sometimes exceed the cap, since in live encoding you do not have the time to go and resample a frame that does exceed the cap.
So yes I'd agree with others that trying a lower cap in the 500 to 800Kbps region would be a good idea
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
Hmm. This is all VERY interesting. I have never had to consider throughput before.
I will access the cameras and lower their bitrate. to something like 512Kbps and wait and see if they stabilise, increasing this over time until the routers fall over.
By the way I can't recall seeing much about RAM in router specs. I wonder if there are routers out there that are designed with live video streaming in mind?
Thank you ALL very much for sharing your knowledge. I will keep you posted over the weeks.
Kevin
|
|
|
Video streaming should have the same impact as any other TCP based task, or UDP depending on the protocol used by the stream. So should not need a router with massive CPU and memory, the issue may be more about whether the firmware is totally bullet proof and has no memory leaks or bugs that cause it to fall over.
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
Yes, very true. And judging by the number of customised firmwares out there I suspect many manufacturers firmware are poor.
|