Depending on when you stopped using that, there have been massive improvements in OpenWrt’s handling of vectoring lines. I ran OpenWrt on my BTHH5 on a 50/10 link (with ~50/10 sync, no vectoring) qiite happily, it was rock solid, but when DT switched my line form a 50/10 sync without vectoring to a 100/40 sync with vectoring (and traffic shaping to my contracted 50/10 rates) the sync started dropping quite often. As it turned out OpenWrt’s DSL drivers failed to send vectoring error samples to the DSLAM resulting in rapidly decreasing SNR and a high rate of sync losses/retrains. But with changes, from end of 2020 IIRC all these problems are gone, and I enjoy uninterrupted DSL sync for weeks/months at a time. In short maybe it is worth retrying the BTHH5 if only to check whether the link is stable with a different modem.
Well, if you have a home box (that is the name?) sitting around, I would certainly try it, just to rule out that your DSL link has issues not related to your side.
Well maybe, I would certainly try a different modem and to contact Allnet to figure out how to diagnose/debug your issue.
Sorry to hear, I guess time to figure out what happens on the DSL side. BTW you are not using powerline adapters in your home network? These are notorious for interfering with DSL (and it does not need to be your PLC adapters, it can be sufficient if one of your neighbors use those).
I would recommend to hook up the BTHH5 with a recent OpenWrt build and use go-dsl to get some numeric information as well os graphs of the SNR- and bitloading-spectra as well as the quiet-line-noise and log graphs. These often can help diagnosing DSL issues.
DLM judged your link to be instable and reduced the DSLAM profile to 100/36 instead of the ‘normal’ 116.800 / 46.720 Kbps limits.
Now that might just be the consequence of your frequent resyncs that DLM correctly interpreted as sign of instability which it then tried to counteract by lowering the sync profile.
It would be helpful if you could also built/run dsl-gui start it, connect to your modem and let it run for say an hour and the post a screen shot of the full window, including the graphs here…
EDIT: just saw the graphs, please ignore the paragraph above…
The wavy pattern in the uplink bands is not looking too great, but not a clear reason for frequent resyncs either…
I guess you should use this modem for the next days to see whether the link stays stable…
just found that exiting tool “vdsl_cpe_control”. is there something i can tweak here? can i manually “reset” the adsl fallback situation? after 1 hour i don’t see differences in the stats.
edit: overall i tend to send whole thing back. turris omnia, 1tb msata, vdsl2 sfp…i’m somewhat disappointed.
staying on good old BTHH5A.
100/36 fallback isn’t a problem if i only subscribed to 50/10, right?
and even with those impressive big antennas the signal quality is the same if not worse to the BTHH5
I think you can tweak the downstream SNR margin a bit, whether that helps depends on why your link looses sync…
No, except thay DLM wikk increase yhe rayes ahain if it dems your link stable again, at least in downlosd direction it is not a good sign if DLM continues to restrict the maximal sync. In upstream this is slightly different with DT’s DLM there continouos restricted profiles are ‘normal’.
Back when I got my BTHH5 I also tried it as all in one rputer under OpenWrt, but even with my then 50/10 plan I was CPU limited when trying to run internet speedtests (5GHz WiFi, PPPoE, NAT, firewall, and most costly CPU-wise sqm) and did not reach my exxpected goodput.
At which point I relegated the HH5 as bridged modem and used a separate router (first a netgear wndr3700v2, later I switched to a turris omnia). This worked very well, unrill the ISP enabled vectoring causing the HH5A to loose sync so often, I replaced the HH5A with a broadcom SoC Zyxel modem (bridged). Then IIRC end of 2020? I started testing new lantiq patches for the HH5A which made that device robust and reliable as dsl modem again. Ever since I operate the HH5A as bridged modem (on a 116.7/37 Mbps sinc with a nominal 100/40 plan from O2) with my omnia as router. The omnia has no problem with my load at that speed, heck I even enabled pakon witout noticing any speed reduction/CPU overload. Since I trust team turris, I am quite happy about the omnia’s automatic update feature, my networks safety/security is not only depending on me monitoring security alerts and manually updating my router. But I can understand your position as well.
BTW, it is a bit annoying how problematic VDSL links can get in regards to stability, I for one am quite happy, that a switch to FTTH is coming sooner or later. There are sufficiently stable GPON ONTs in SFP form factor that should work well on an omnia if one desires so, and GPON ONTs offer minimal diagnostics anyway so not much is lost by using a SFP module.
Oh, the higher the SNR margin is the more reserves your link has to deal with noise/interference, so higher numbers typically mean more robust/reliable DSL sync. However this is also a consequence of your Download sync now being capped at 90 Mbps (with the attainable net data rate of 141 Mbps this indicates that DLM still considers your link unstable, but if you have no more resyncs I am confident that DLM will up these limits again, unless it deems your rtx error counters too high).
I would use the HH5A for a few days (without rebooting it) to see whether you get stable link for multiple days, and then maybe try the Allnet modem again to check that your problems are reproducible with the Allnet modem but go away with the HH5a (if that turns out to be true, I would try to talk to Allnet about debugging/diagnosing the issue or returning the modem).
on my 50/10 plan with BTHH5 i only get 33 mbit’s download and excelent 11 mbit upload.
same line with turris + allnet sfp i get 55 mbit download. a cpu lilmitation? can’t figure it out.
so i have a high speed vs stable connection choice.
I can not tell you about recent OpenWrt but back when I tried with the HH5A as full OpenWrt router I was hitting CPU limits as well. So I reconfigured it as bridged modem and now it works well up to the expected throughput for my 116/37 Mbps sync. To test that you could install and run htop on the CPU-limited (make sure to enable the detailed color code for the CPU bars so you also see the soft interrupts (sirq) shown, often kernel networking is done in SIRQ-context so you need to look at that as well).
Or you try the HH5A as bridged modem leaving all the heavy lifting (PPPoE, NAT, firewall, WiFi, SQM?) to your turris omnia, then you might max out your 50/10 link… while (hopefully) keeping a stable sync (please note I would monitor the link for a few days before declaring “stable connection”, things like interfering devices might not always be active…)
i never want to have 2 devices in my room. from the moment i heard form the sfp module i was dreaming of a new single open source router as a succesor to the BTHH5. so having 2 devices in my room standing around is no option for me.
by the way i measured power comsumption and they both take around 6W. is this realistic? i’m not sure if my meter is working correctly.
Well, these are your rules and it is your prerogative to play by your own rules. But in that case you might want to look over at the OPpenWrt Forum in this thread:
where folks got FritzBox7520/7530 all-in-one routers to work with OpenWrt. The required patches are currently being offered for the main development branch, but ATM one needs to build from an external github repository IIRC. That would give you a DSL all-in-one that should be a bit less CPU-limited than your HH5A.
BTW, in my case the devices are not in the same room, the modem located where the POTS line enters the apartment, and then I have a cat5e ethernet cable to the place for my WiFi router; so both are sitting at a decent place to fulfill their purposes (low-interference with hoe devices for the DSL-modem and decent WiFi coverage for the router). But I can see that with a single room apartment it is likely that WiFi coverage will work from where the TAE is located… (Initially my TAE was where the router lives now, but I removed ~12 meters of low quality POTS wiring to improve my DSL SNR and that moved the “TAE” further away from the router location, scare quotes, as I did not attach a TAE, but an old ISDN 8P4C-modular socket to the POTS line.)
Over in this thread:
I reported my measurements of average power draw:
6.89 Watts for my bridged BT HomeHub5A
7.98 Watts for my Turris Omnia
details about the measurement over in that thread*. Modern Fritzbox all-in-one routers are reported to be in the 11-15 Watt range, so my combination is on the high end, but not completely above theAIO range (even if I add the ~1 Watt for my VoIP-base-station).
*) Consumergrade powermeters are typically not that precise especially for low power consumers, but I would gues the error to be <= 20% and so the numbers are still useful.
I obviously have no data for the additional power draw when adding an allnet SFB modem to the omnia.
wow, the 7520/30 got it on the list of supported devices! haven’t seen this when i frequently check openwrt page for new devices. i found a used one and i will catch it later. if the cpu performance is at least twice the time i dont need turris omnia anymore. thank you!
I am not sure that is correct yet. Please read the thread. There is a PR to integrate this into the main branch, but:
a) it is not guaranteed to make it in
b) it does not come with necessary firmware files, so these need to be downloaded separately
Also IIRC some folks found that some FB7520 could not be converted to OpenWrt successfully, but no one knows currently why.
Finally, I have never tried any of those repositories/patches myself, as I do not own a FB 7520/30 (as the bridged BTHH5A achieves almost full-sync there is little fr me to improve, sure in upload direction if I could escape the grasp of DLM I could potentially improve from37 Mbps to maybe 40 Mbps, but is such a small potential gain worth > 50EUR?)
So the FB7520/30 (FB) sport a quadcore 716MHz Arm A9 (32bit) CPU with 256 MB ram, while the turris omnia (TO) sports a dualcore 1.6GHz Arm A9 (32bit) CPU with 1 (or 2) GB ram Whether the FB or the TO will be faster depends on the task(s) at hand, but for most things the TO should be equal or faster than the FB (0.716*4 = 2.864, 2 * 1.6 = 3.2) but some things could be faster on a quad core than a dual core.
Both should run circles around the HH5A’s dualcore 500Hz MIPS 34Kc CPU and should limit your achievable rates.
