New Router Test Processes Are Coming

[sfx2000]

I'd love to check how well (or whether) IPv6 functions. But there is no equivalent of the standard DHCP WAN configuration all routers support for IPv4 that is consistently supported for IPv6.

Having an IPv6 DHCP WAN type is necessary but not sufficient. How the LAN handles addressing is just as important and that's where things get messy...

I'm sure you've reached out to the suppliers - both for the test equipment and Vendors/OEM's on feedback - but as you state, it's the WAN connectivity that is problematic... but if one were to stand up a small DCHP6-PD "WAN" server, this might help - at least to get a baseline performance, as this is fairly common (it's the options that are tough across different operators, Comcast and Cox have both had issues here - Cox's is ongoing even now, as they pretty much rolled out v6 in the last couple of months)

 

[thiggins]

CDRouter can test all the IPv6 connection types. It's the equipment that is inconsistent. Not all support PD, for example.

Give it another couple of years....

 

[pete y testing]

Ok, guys, got the point on storage. Any other comments on the other aspects of the preview?

any chance of testing in the windows environment with standard samba copy and paste as well as icharriot results , i know its a lot of extra work but its also a better indication of how the router works in a standard user environment and what the end use can expect to see when the just copy and paste between devices

pete

 

[sfx2000]

any chance of testing in the windows environment with standard samba copy and paste as well as icharriot results , i know its a lot of extra work but its also a better indication of how the router works in a standard user environment and what the end use can expect to see when the just copy and paste between devices

I think part of the challenge these days - what is a standard SMB environment?

Windows Clients/Servers is a mixed bag - OSX Client to Linux SMB3 server on a NAS? No Windows there, mate...

iPerf UDP/TCP numbers are probably a better benchmark of actual performance...

 

[pete y testing]

iPerf UDP/TCP numbers are probably a better benchmark of actual performance...

but to the average man on the street jipref doesnt make a lot of sense apart from one being higher than another , and dont really give the average user an idea of what they can expect when they transfer from one device to another

i know the jipref is the preferred method on snb but a simple benchmark set in MB/s would be beneficial to the readers and to the overall review

just my point of view

pete

 

[sfx2000]

i know the jipref is the preferred method on snb but a simple benchmark set in MB/s would be beneficial to the readers and to the overall review

all numbers are relative though... just my thoughts...

 

[stevech]

IPv6; we'll need to go there sooner than later.

Started hearing that from DoD and others some 15 years ago.
Will the barrage of IoT thingies all be NATed too? I think so.

 

[pete y testing]

all numbers are relative though

true but how they relate to the end user is the key

 

[System Error Message]

The only problem with star tech is that they stuff is usually overpriced for the quality it provides. If you are worried about emf than you need a metal/aluminium case for the drive. The only quality star tech product i have is an open and adjustable server rack on wheels and even that was very expensive.

Esata is still used around. On some desktops you have an esata port that connects to motherboard SATA. It basically connects an internal sata to external so you dont get usb overheads depending on if sata is connected to chipset or some extra chip. Its too bad a lot of manufacturers didnt adopt esata but part of the problem was that you needed another power source compared to usb and by the time powered esata came out you already had usb3 and all people want are convenience and dont seem to care about overhead and that extra performance.

Aside from performance testing feature testing should be done too such as with ipv6 and mixed ipv6 and ipv4 environments. Bug testing where if every feature was used, would the router hang after being fully loaded for a while? Dont forget to test reliability.

 

[thiggins]

any chance of testing in the windows environment with standard samba copy and paste as well as icharriot results , i know its a lot of extra work but its also a better indication of how the router works in a standard user environment and what the end use can expect to see when the just copy and paste between devices

If you are referring to the storage throughput tests, Windows Robocopy is used
http://www.smallnetbuilder.com/lanwan/lanwan-howto/32612-how-we-test-router-storage-performance

iperf/Jperf has not been used in any of the current benchmarks.

 

[pete y testing]

If you are referring to the storage throughput tests, Windows Robocopy is used

well i was more wanting wireless throughput also measured that way as well

 

[thiggins]

well i was more wanting wireless throughput also measured that way as well

Sorry, that is not going to happen.

 

[GJJ]

After reading a post about different h/w revisions for a particular router and what the different chipsets each revision brought to the table, I'd like to see testing of concurrent activities. As it was said in the initial article, we're using our routers for a lot of different things now days, but the way I have read the tests, is that they're only testing 1 aspect of the router at a time.

The post was about different revisions for the Asus RT-AC68U (excuse me if I remember the wrong: it's mostly for example purposes.)
A1/2 - Base config
B1 - Updated cpu running 200MHz faster
C1 - Not released yet, but supposedly with different wifi chips that offload some of the work from the main cpu

In the tests that have been used until now, I wouldn't expect to see much if any significant difference between rev. B1 and C1.
However if there was a load test, that was loading up the wifi components and the routing components at the same time, I'd expect to see a more noticeable improvement with the newer C revision.

Some sort of mixed load test would also show up differences between single and multi core routers when some users are doing LAN-WAN work, while others are accessing a storage device connected to the router via USB.

Agreed, there are a lot of different router hardware combinations out there, but some "simple" mixed load testing could show up differences in hardware and firmware configurations. (I say "simple", but I doubt the tests would be simple to standardise and run.)

Anyway, just an idea.

Greg

 

[thiggins]

Wireless load testing using the Veriwave system is planned. It may not be in the initial process release.

 

[GJJ]

Cool thanks.

I saw that in your initial article, but wasn't sure what was meant by it.

I'll be interested to see it when it arrives, even if not initially.

Greg

 

[bman212121]

Which is likely part of the problem. I've been consistently just disabling IPv6 on everything I've setup because it just doesn't work. When all of your networking / sys admin contacts are doing the same and going out of their way to disable a feature, there certainly is a problem.

 

[mactenchi]

Tim, any chance for a long-term component to testing? I find performance/features degrade over time. For example, my Archer C7 seems to need a hard restart periodically to fix NAT.

 

[thiggins]

Tim, any chance for a long-term component to testing? I find performance/features degrade over time. For example, my Archer C7 seems to need a hard restart periodically to fix NAT.

Unlikely. Most I could do would be to loop the functional tests overnight. Doubt that would help much.

 

[L&LD]

Unlikely. Most I could do would be to loop the functional tests overnight. Doubt that would help much.

You could ask the manufacturers for a few dozen units to send to your closest friends for 'long term testing', can't you?

(No, I'm not volunteering or suggesting we're actual 'friends').

 

[mactenchi]

Unlikely. Most I could do would be to loop the functional tests overnight. Doubt that would help much.

Might be interesting to try, see if results change. Probably not worth adding to the test process, though, you're right.