Findings about nstreme test 9

We’ve installed a 2 km link and start testing nstreme… The tests we’ve wade was:

  1. ping in interval of 10ms, 64 byte packet size
  2. bandwidth test: no random data, protocol=tcp, direction=both

Results without nstreme:

100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max = 1/2.5/16 ms

                  status: running
                duration: 30s
              tx-current: 15Mbps
    tx-10-second-average: 15Mbps
        tx-total-average: 14.9Mbps
              rx-current: 15.1Mbps
    rx-10-second-average: 15Mbps
        rx-total-average: 14.9Mbps

Results with nstreme and framer-policy=none

100 packets transmitted, 57 packets received, 43% packet loss
round-trip min/avg/max = 1/2.1/15 ms

                  status: running
                duration: 30s
              tx-current: 12.2Mbps
    tx-10-second-average: 11Mbps
        tx-total-average: 10.8Mbps
              rx-current: 12.2Mbps
    rx-10-second-average: 11Mbps
        rx-total-average: 10.8Mbps

Results with nstreme and framer-policy=fast-frames

100 packets transmitted, 77 packets received, 23% packet loss
round-trip min/avg/max = 1/2.6/16 ms

                  status: running
                duration: 30s
              tx-current: 9.72Mbps
    tx-10-second-average: 10.5Mbps
        tx-total-average: 10.7Mbps
              rx-current: 9.61Mbps
    rx-10-second-average: 10.5Mbps
        rx-total-average: 10.7Mbps

Results with nstreme and framer-policy=best-fit

100 packets transmitted, 86 packets received, 14% packet loss
round-trip min/avg/max = 1/3.3/16 ms

                  status: running
                duration: 30s
              tx-current: 11.3Mbps
    tx-10-second-average: 10.6Mbps
        tx-total-average: 10.6Mbps
              rx-current: 11.3Mbps
    rx-10-second-average: 10.6Mbps
        rx-total-average: 10.6Mbps

Results with nstreme and framer-policy=exact-size

100 packets transmitted, 75 packets received, 25% packet loss
round-trip min/avg/max = 1/2.3/16 ms

                  status: running
                duration: 30s
              tx-current: 8.84Mbps
    tx-10-second-average: 10.2Mbps
        tx-total-average: 10.5Mbps
              rx-current: 8.85Mbps
    rx-10-second-average: 10.2Mbps
        rx-total-average: 10.5Mbps

You can see the huge packet loss. We are using Atheros 5211 cards. The framer-limit is 3200

We will check on this. There will be a new version of Nstreme in the next week that will have allot of changes, so the protocol is not complete yet.

John

still, I consider 15Mbit on 2km to be really slacked up…

Sounds like interference or a low quality link – if this is the result from UDP 1500 byte packets. If on regular traffic, you have this speed, it could be normal (if there are allot of smaller IP packets).

John

And you tried to convince me nstreme was stable. ;>
Argueing about semantics is however not what i want, vlan over wds works in v2.8.12 so i am happy :slight_smile:

If you have a bad connection, then the framer should be set for 1600 or so. The next version will have dynamic framer policy settings.

Also, you should use UDP for the test.

John

I have never said that the current versions are the full release. Most of the changes are simply new features – not fixes. I hear there are number of people already running large networks on Nstreme, upgrading may be an issue.

John

99% of Internet trafic is TCP, why shoud I use UDP?

35 MBit one-direction test, 15 MBit in both directions(sum: 30 MBit)

The UDP test speed is higher than TCP. But no used at all.www,email,ftp…
is TCP

[asm], 35Mbit is maximum you can have. That’s it, your line is running full-speed. BTW, what kind of hardware do you use? Routerboard ? Having 35Mbit UDP and only 15Mbit TCP is kinda low - but hey, you used 64 byte packets… Ok, so that’s nice result :slight_smile:

I have 35 Mbit TCP in one direction, and 30 MBit summed TCP in both directions. The hardware is old IBM Pentium 2 @ 400MHz 64 MB RAM.

You need to study the protocols to understand this – try google.

John

Our dev version of Nstreme has 44Mb/s running with a single radio, no turbo, celerons, and sitting next to each other!

I think the reason that the RouterBOARDS were running slower with Nstreme than 802.11 (when links are not long) was because Nstreme has a higher CPU overhead and is basically made to get around the built in bottlenecks of 802.11 concerning distance and some other things.

John

Which MAC Controler did they use? Atheros 5211 or 5212? Because with 5212 I’ve made 52 MBit in 802.11a (in turbo mode) sitting each other

Test test units have 5212. The 5211s are limited for large frame sizes, so in a radio environment where the signal is perfect, the 5212s will go faster. Probably for most environments, this will not make a difference.

John