So it's totally normal. You'll never pull more than the speed of the fastest single connection in a single file transfer. The file will have to be split and sent in pieces... then you can take advantage of both connections.
Multithread test aside, you should be able to open two browser windows on the download test and start a larger test manually (one that will give you at least 10-15 seconds) on both windows. Try to do it quickly. If your bonding is balancing the load well the tests shouldn't affect each other. And you'll get two similar results... which you can then combine to get a total aggregate speed. As long as the two tests started at nearly the same time the final combined number should be highly accurate. (though not perfect because the tests were initiated by hand, staggered start time will raise the score slightly.) --- this scenario is only two threads but the score should be close to what you get in the multithread test if things are running well. ... this is one of the reasons I say "Versatile" on the home page. If you're smart you can use this test is different ways for which it wasn't originally designed and it still works.
Good to know - I did notice on the multi-thread that it appeared to be balancing across my WAN ports - which was a good sign for me. In all honesty, the intent of bonding the second connection was to be able to load balance the connection when it took a dive in the evening. Which seems to have worked last night when I was at work. While it was not perfect, it does appear to have at least alleviated a measure of the issue since I am splitting the data between the two connections. VoIP is is obviously not affected in this test because that traffic establishes its session then stays on that interface.
BTW, this bonding was at the suggestion of the tech because he noticed the router and noted I had a DSL backup connection attached to it.
I do not know how long Cox will let me have the second interface for free so, obviously getting them to resolve the single interface issue of utmost priority.
Were you able to review my results Ca3le? Any thoughts? Cox denies the node is overloaded but also noted the node is only putting out 70 mbs where the other nodes nearby are putting out around 140 - 160 mbs. The also told me they know they are only getting 1.3 - 1.5 volts on the fiber signalling from the Office to our area (hope I stated that correctly) where I was advised by the Plant Tech it should be 3 volts. Evidently, Cox was aware of the shortfall and had plans for a fiber amplifier between our area and the main office but scrubbed it due to budget. All the signal levels from what I could read 'over the shoulder' at the tap were nominal Friday - which was a big change from Monday where we were seeing 2 - 4 % packet loss and 90+ ms jitter on VoIP tests and throughput tests to the tap of about 40mbs.
Admittedly, I know enough about the WAN side of things to be dangerous which is the reason I am reaching to the forums for help. The speed drops may cost me my job since I telecommute if I don't get them resolved soon.
Thank you for any additional insight you might be able to provide.