Belgacom’s BBOX2 wastes resources
9 April 2010 | Published in BBox-2 | 23 Comments
Belgacom, we have (yet another ) problem with your BBox2 modem.
A background management daemon like TR-98 just cannot be allowed to use 96% CPU all the time, even when doing nothing. Please fix this, or fire your supplier.
Further, I do not use your SIP service, so please give me a way to disable the sipd process. It uses 48% of the available memory.
This is not an efficient use of resources and certainly not “green”.
Update 19 June: After following Ced’s advice below, I killed the sipd, tr69 and tr98 processes and got the following results
As you can see, more memory is freed and the average load has been divided by two.
Share on Twitter
9 April 2010 at 15:08 (#)
This could actually make sense. The tr98 (traffic routing?) process checks for new input constantly instead of waiting for an interrupt, which speeds up routing. JUNOS does this.
9 April 2010 at 15:27 (#)
Actually, TR-098 is a BroadBand Forum specification for the remote management and configuration of home CPEs. It complements TR-069. So, there is nothing related to traffic routing.
http://www.broadband-forum.org/technical/download/TR-098_Amendment-2.pdf
14 June 2010 at 6:25 (#)
Kan we not just give a kill or killall command to stop that those processes we d’ont really need ??
I use the Bbox2 with a linksys wrt 54 gl with tomato firmware.
The linksys does the pppoa session, so the Bbox acts as a dumb modem. I d’ont need those processes running all the time i guess.
Zwintje
14 June 2010 at 10:07 (#)
There is no ‘kill’ command in the BBox-2′ shell. There is no way to edit the list of processes started at boot-up either. Remember it is a scaled-down Linux box, not a full RedHat/Debian/whatever distribution.
19 June 2010 at 20:39 (#)
I havé the fast modem from sagem and I managed to kill the process by simply using the command kill.
I do not understand why you can t do it on the box
19 June 2010 at 21:02 (#)
@Ced Yes, you are correct. There is a ‘kill’ command, as well as a ‘killall’. So, ‘killall sipd’ will indeed end all the VoIP processes. For some reason, it did not work for me the first time I tried it.
28 June 2010 at 17:29 (#)
Hello Patrick!
Very nice site, really, I think I’ll come back a few times!
May I ask what is the command in telnet you used so as to see the processes and resources used?
Thanks in advance.
28 June 2010 at 18:46 (#)
@serge the command is ‘top’
1 July 2010 at 12:36 (#)
Patrick, I just noticed that after I killed the tr98 process yesterday, it has automatically come up again. Same for the SIPD process.
1 July 2010 at 13:01 (#)
@Seb I verified on the BBOX2. Its behaviour is different. What is killed remains so until the next reboot. +1 for the BBOX2, i guess
4 July 2010 at 3:07 (#)
I d’ont that much about linux, but maybe we kan rename the files used for those processes like TR98 or voip.
So next time the bbox reboots he simply can not start those processes.
If in future we do need the processes, we simply give them back the original name.
Zwintje.
4 July 2010 at 14:44 (#)
@Zwintje Actually, the whole filesystem is read-only, much like a CD-ROM. There is no way to rename/delete files.
5 July 2010 at 23:20 (#)
Good info here
If I telnet to my BBOX2, ‘top’ command doesn’t seem to exist?
6 July 2010 at 6:24 (#)
@Phil Once you logged in, make sure you type “shell” to access BusyBox. “top” is an internal command in BusyBox.
What I have noticed is that, sometimes, any command at the prompt is ineffective. Even “ls” or “exit”. If I try a few minutes later, it usually works again. Don’t ask me why …
12 July 2010 at 23:00 (#)
Absolutely amazing that this process is such a nasty CPU hog. I killed the TR98 process and no major problems to report except for one (which I think is totally unrelated)… anybody having problems with Apple devices (Macbook, iPad) randomly disconnecting from the BBOX2 WiFi?
28 July 2010 at 22:19 (#)
OLD news!
This was already reported years ago on the belgacom forums
29 July 2010 at 21:19 (#)
@Tom: It may be old news, although:
1. The BBOX2 is not as old (“years ago”) as you seem to imply and
2. I did not find any reference to this behaviour before I posted it on 9 April, and certainly not on the Belgacom forums, which seem to be dead and totally abandoned by the BGC staff.
I certainly make no claim to have been the first one to discover that behaviour. But It was sufficiently annoying to be worth a blog post.
31 July 2010 at 22:15 (#)
I think that the BBOX is not using 96 % of its total cpu time for tr98. When you look to the total load on top of your screen, you will see there is only about 2% cpu load.
Of that 2% TR98 uses 96% CPU time.
I have killed TR98 en the sip process, and after some time other processes go to much higher cpu time, and the total gets back to 100 %. WSCCMD now uses 95% of the cpu time.
Edwin
4 August 2010 at 20:38 (#)
@Edwin: The “2.06″ on the top line is not a percentage. See this explanation on Wikipedia. Rather, a load average higher than 1.0 means the CPU is potentially overloaded.
12 August 2010 at 13:20 (#)
> 2. I did not find any reference to this behaviour before I posted it on 9 April, and certainly not on the Belgacom
I searched *2 seconds* and I found this:
http://forum.belgacom.net/view.php?bn=selfcareforumnl_bugs&key=1248382769
From July 2009 …
>1. The BBOX2 is not as old (“years ago”)
Yes it is, exactly 2 years old.
And kill doesn’t solve your problem, as it will be restarted automatically.
Also, it will stop updates from Belgacom and can result in reboot of the modem.
>Rather, a load average higher than 1.0 means the CPU is >potentially overloaded.
Not true. Above 10 you can call ‘overloaded’, but still not dying.
12 August 2010 at 14:38 (#)
@Wim
>I searched *2 seconds* and I found this:
Thanks for the link. It is especially worrying that this problem has been reported this long ago to BGC, but still not solved.
> And kill doesn’t solve your problem, as it will be restarted automatically.
> Also, it will stop updates from Belgacom and can result in reboot of the modem.
It is only restarted at boot time, which does not happen very often. Actually, when the tr98 process is inactive, the Bbox2 does not spontaneously reboot at all.
I suspect spontaneous reboots are related to the high load generated by the tr98 process and the memory used by the sipd processes. As for the updates, you are right. I usually wait to hear from other people’s experiences with new firmware versions before allowing my modem to update itself. The lack of information from BGC regarding these updates do not help either.
The difference of opinion on the meaning of the “load average” is as old as Unix itself. It very much depends which kind of machine you are talking about. On a typical CPE with a a low end CPU I would not be concerned for spikes above 1.0. However, a constant load of more than 2.0 over 15 minutes does look strange.
21 August 2010 at 11:35 (#)
Really nice info! So what you are saying is that the tr98 and tr69 processes are responsible for the belgacom firmware updates and the sipd processes are for the VOIP services?
I don’t use VOIP, but a regular telephone line, and I don’t really need automatic updates. If a new one is posted, I can reset the router, let it update and kill the processes again.
Have you noticed any adverse effects when killing the processes, or would you say it’s safe?
Also, have you noticed the bbox2 running cooler, or have you measured the drop in power consumption? I’ve got a power meter here somewhere, so I can check it if you want.
21 August 2010 at 17:23 (#)
@M3TT3 Well, the updates could be beneficial. For example, the rumor is that the latest update is supposed to allow greater speeds on VDSL2, by enabling the 17Mhz profile. Due to Belgacom’s culture of secrecy, we don’t know for sure. But, as you say, you can re-enable the updates it by doing a reset, or reboot the box and enable VLAN20.
From personal experience,my modem is a bit cooler now those processes are killed. Note, however, that the original Sagem has a different case than the BBOX-2, and tends to be hotter because of that.
I have seen no adverse effects in killing those processes, and one major benefit: the Box does not reboot randomly as it did before. It has been stable now for more than two months, without a single reboot.