[Cerowrt-devel] lede integration issues remaining from the detrius of cerowrt

[Dave Taht <dave.taht@gmail.com>]

happy to see cake working today! thx all!

In https://github.com/dtaht/ceropackages-3.10:

A) We have flent's tc-iterate.c as a fast, lightweight means of
polling fq_codel, pie, cake stats (as the shell in openwrt doesn't
support a subsecond sleep) for openwrt.

(However this package and code is in need of iteration to support
polling the new stats presented in the fq_codel for wifi sysfs code.)

Having something like this working is essential to analyze the real
performance and correctness of the new implementations on the low end
hardware.

B) I am probably the only user of the gnugol package. :(

C) I really need to sync the isochronous code with what avery has upstream

D) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/nanom5poe

I don't know what landed upstream to control poe for the nano-m5
radios, if anything?

E) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/gdisk

The principal problem with fdisk nowadays is that very large (> 2TB, I
think) devices are not supported by it, and require a GPT capable
tool. Is there a replacement in lede that handles GPT? If not - this
is an old gdisk port to openwrt that I used to use.

F) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/cerowrt-scripts
was a tool we used to measure latency under load directly on the
router...

some other packages that might be worth upstreaming, or putting in
another repo or updating in ceropackages

owamp: lets us measure ping times very precisely. (requires good ntp)
ntpsec - a vastly hardened full fledged ntp fork https://www.ntpsec.org/
scamper - two other measurement tools
shaperprobe

?

G) We used lighttpd in cerowrt as it was tons faster than uhttpd and
flexible enough to also do local web serving. can it (or ngnix) be
substituted for uhttpd? Or has uhttpd got faster?

H) Anyone working on go or rust for lede? hugo and ipfs and all the
other blockchain related distributed web bits looks like fun...

It looks like the static linking in go is a deal-killer

https://github.com/GeertJohan/openwrt-go/issues/2