A couple discoveries:
1) My frequent disconnects appear to be specific to the SBG6580's wireless. Using InSSIDer I was able to locate a clean wireless range, but this made NO difference on wireless stability to/from this device. I even put my laptop right next to the device (literally 3 feet away) and still only had a signal strength of -50 to -45 (this is ** for wireless) and it's even worse from nearby rooms. As a result, I have re-installed my aging Cisco wireless router.. I now no longer have wireless dropping issues. Since Cox is in charge of firmware updates I am unable to install and try newer firmware to see if the problem is resolved.
2) The Web UI of the SBG6580 is horribly slow, and it's not just the web ui but is in fact the entire device. For example, if I use the diagnostic ping and tracert utilities from the device I get horrible results, whereas the same ping and tracert tests from a wired or wireless device yield much better results. Apparently the performance of the device was negatively impacted with the 3.5.x series of firmware updates, this can be found in a number of posts not only from Cox but other cable networks.
3) All else aside, I found a post that noted that 192.168.100.1 was an 'internal' IP for the modem, the ping and tracert results look the same from wired and wireless devices. I then ran a ping against this IP side-by-side with a ping against the WAN IP reported by the modem (presumably. this is the IP of the appliance on the other end of the cable connection?) Notice how response times spike throughout the test in both pings, as my ping to local degrades so does my ping to remote, and with seeming equality.)
I *believe* these should be closer to 10-20ms (if not less, considering this doesn't actually leave the device and a direct, switched IP shouldn't take 10ms to travel between a wired NIC and a router). I *suspect* this is also linked to the generally poor performance of the device, which I've gathered is related to the firmware Cox is pushing out based on a few posts made by others that noted the poor performance after an update went out last year. To test this theory I started a ping test, logged into the device and then refreshed the device's login page, every time I did this my ping results would jump 300-1300ms until the device login page was finished refreshing.
Perhaps Cox should add this to their rigorous test plan when evaluating device firmware?
I don't mean to finger-point at Cox nor the firmware they're pushing, but it's an area I can't personally explore by swapping firmware versions, and since this seems like an easily reproduceable problem *shrug* seems like a legit suggestion. Based on my limited searching this morning the performance degradation of the device was introduced sometime after the 3.2.x firmware version (3.3.1 or later?).
I suspect this poor device/switching performance not only affects wired connections and WAN performance, but also affects wireless performance and that wireless usage of the device may actually be contributing to the poor performance and instability of the device.
Here is the wired tracert and ping results to 192.168.100.1 and to my immediate WAN gateway, again note if you place the ping results side by side each ping line item/result value nearly corresponds with one another, and the ping latency is present to both IPs is nearly identical.
========
C:\Users\Shaun>tracert 192.168.100.1
Tracing route to 192.168.100.1 over a maximum of 30 hops
1 50 ms 25 ms 308 ms 192.168.100.1
Trace complete.
========
Tracing route to ip68-4-153-128.oc.oc.cox.net [68.4.153.128]
over a maximum of 30 hops:
1 158 ms 130 ms 427 ms ip68-4-153-128.oc.oc.cox.net [68.4.153.128]
Trace complete.
========
Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time=23ms TTL=64
Reply from 192.168.100.1: bytes=32 time=37ms TTL=64
Reply from 192.168.100.1: bytes=32 time=962ms TTL=64
Reply from 192.168.100.1: bytes=32 time=93ms TTL=64
Reply from 192.168.100.1: bytes=32 time=20ms TTL=64
Reply from 192.168.100.1: bytes=32 time=21ms TTL=64
Reply from 192.168.100.1: bytes=32 time=1222ms TTL=64
Reply from 192.168.100.1: bytes=32 time=112ms TTL=64
Reply from 192.168.100.1: bytes=32 time=1298ms TTL=64
Reply from 192.168.100.1: bytes=32 time=533ms TTL=64
Reply from 192.168.100.1: bytes=32 time=180ms TTL=64
Reply from 192.168.100.1: bytes=32 time=1482ms TTL=64
Reply from 192.168.100.1: bytes=32 time=565ms TTL=64
Reply from 192.168.100.1: bytes=32 time=414ms TTL=64
Reply from 192.168.100.1: bytes=32 time=157ms TTL=64
Reply from 192.168.100.1: bytes=32 time=364ms TTL=64
Reply from 192.168.100.1: bytes=32 time=138ms TTL=64
Reply from 192.168.100.1: bytes=32 time=85ms TTL=64
Reply from 192.168.100.1: bytes=32 time=43ms TTL=64
Reply from 192.168.100.1: bytes=32 time=12ms TTL=64
Reply from 192.168.100.1: bytes=32 time=284ms TTL=64
Reply from 192.168.100.1: bytes=32 time=1016ms TTL=64
Reply from 192.168.100.1: bytes=32 time=322ms TTL=64
Reply from 192.168.100.1: bytes=32 time=597ms TTL=64
Reply from 192.168.100.1: bytes=32 time=77ms TTL=64
Reply from 192.168.100.1: bytes=32 time=489ms TTL=64
Reply from 192.168.100.1: bytes=32 time=309ms TTL=64
Reply from 192.168.100.1: bytes=32 time=234ms TTL=64
Reply from 192.168.100.1: bytes=32 time=65ms TTL=64
Reply from 192.168.100.1: bytes=32 time=249ms TTL=64
Reply from 192.168.100.1: bytes=32 time=79ms TTL=64
Reply from 192.168.100.1: bytes=32 time=967ms TTL=64
Reply from 192.168.100.1: bytes=32 time=102ms TTL=64
Reply from 192.168.100.1: bytes=32 time=221ms TTL=64
Reply from 192.168.100.1: bytes=32 time=50ms TTL=64
Reply from 192.168.100.1: bytes=32 time=219ms TTL=64
Reply from 192.168.100.1: bytes=32 time=50ms TTL=64
Reply from 192.168.100.1: bytes=32 time=236ms TTL=64
Reply from 192.168.100.1: bytes=32 time=40ms TTL=64
Reply from 192.168.100.1: bytes=32 time=210ms TTL=64
Reply from 192.168.100.1: bytes=32 time=31ms TTL=64
Reply from 192.168.100.1: bytes=32 time=897ms TTL=64
Reply from 192.168.100.1: bytes=32 time=131ms TTL=64
Reply from 192.168.100.1: bytes=32 time=274ms TTL=64
Reply from 192.168.100.1: bytes=32 time=50ms TTL=64
Reply from 192.168.100.1: bytes=32 time=391ms TTL=64
Reply from 192.168.100.1: bytes=32 time=55ms TTL=64
Reply from 192.168.100.1: bytes=32 time=265ms TTL=64
Reply from 192.168.100.1: bytes=32 time=54ms TTL=64
Reply from 192.168.100.1: bytes=32 time=235ms TTL=64
========
Pinging 68.4.153.128 with 32 bytes of data:
Reply from 68.4.153.128: bytes=32 time=54ms TTL=64
Reply from 68.4.153.128: bytes=32 time=42ms TTL=64
Reply from 68.4.153.128: bytes=32 time=1152ms TTL=6
Reply from 68.4.153.128: bytes=32 time=98ms TTL=64
Reply from 68.4.153.128: bytes=32 time=49ms TTL=64
Reply from 68.4.153.128: bytes=32 time=47ms TTL=64
Reply from 68.4.153.128: bytes=32 time=1269ms TTL=6
Reply from 68.4.153.128: bytes=32 time=112ms TTL=64
Reply from 68.4.153.128: bytes=32 time=1284ms TTL=6
Reply from 68.4.153.128: bytes=32 time=547ms TTL=64
Reply from 68.4.153.128: bytes=32 time=195ms TTL=64
Reply from 68.4.153.128: bytes=32 time=1496ms TTL=6
Reply from 68.4.153.128: bytes=32 time=562ms TTL=64
Reply from 68.4.153.128: bytes=32 time=415ms TTL=64
Reply from 68.4.153.128: bytes=32 time=154ms TTL=64
Reply from 68.4.153.128: bytes=32 time=361ms TTL=64
Reply from 68.4.153.128: bytes=32 time=154ms TTL=64
Reply from 68.4.153.128: bytes=32 time=84ms TTL=64
Reply from 68.4.153.128: bytes=32 time=11ms TTL=64
Reply from 68.4.153.128: bytes=32 time=13ms TTL=64
Reply from 68.4.153.128: bytes=32 time=289ms TTL=64
Reply from 68.4.153.128: bytes=32 time=1028ms TTL=6
Reply from 68.4.153.128: bytes=32 time=322ms TTL=64
Reply from 68.4.153.128: bytes=32 time=594ms TTL=64
Reply from 68.4.153.128: bytes=32 time=74ms TTL=64
Reply from 68.4.153.128: bytes=32 time=490ms TTL=64
Reply from 68.4.153.128: bytes=32 time=307ms TTL=64
Reply from 68.4.153.128: bytes=32 time=237ms TTL=64
Reply from 68.4.153.128: bytes=32 time=67ms TTL=64
Reply from 68.4.153.128: bytes=32 time=247ms TTL=64
Reply from 68.4.153.128: bytes=32 time=72ms TTL=64
Reply from 68.4.153.128: bytes=32 time=967ms TTL=64
Reply from 68.4.153.128: bytes=32 time=102ms TTL=64
Reply from 68.4.153.128: bytes=32 time=45ms TTL=64
Reply from 68.4.153.128: bytes=32 time=43ms TTL=64
Reply from 68.4.153.128: bytes=32 time=213ms TTL=64
Reply from 68.4.153.128: bytes=32 time=44ms TTL=64
Reply from 68.4.153.128: bytes=32 time=37ms TTL=64
Reply from 68.4.153.128: bytes=32 time=39ms TTL=64
Reply from 68.4.153.128: bytes=32 time=212ms TTL=64
Reply from 68.4.153.128: bytes=32 time=33ms TTL=64
Reply from 68.4.153.128: bytes=32 time=898ms TTL=64
Reply from 68.4.153.128: bytes=32 time=133ms TTL=64
Reply from 68.4.153.128: bytes=32 time=269ms TTL=64
Reply from 68.4.153.128: bytes=32 time=45ms TTL=64
Reply from 68.4.153.128: bytes=32 time=393ms TTL=64
Reply from 68.4.153.128: bytes=32 time=50ms TTL=64
Reply from 68.4.153.128: bytes=32 time=264ms TTL=64
Reply from 68.4.153.128: bytes=32 time=49ms TTL=64
========
Thoughts? As a final note, if I disable nearly all network usage (leaving only my bitcoin miners running, which are low-demand as is) and then re-initiate ping to 192.168.100.1, it looks more like this:
C:\Users\Shaun>ping -t 192.168.100.1
Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time=21ms TTL=64
Reply from 192.168.100.1: bytes=32 time=21ms TTL=64
Reply from 192.168.100.1: bytes=32 time=296ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=56ms TTL=64
Reply from 192.168.100.1: bytes=32 time=328ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=442ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=67ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=16ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=16ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Reply from 192.168.100.1: bytes=32 time=10ms TTL=64
Reply from 192.168.100.1: bytes=32 time=11ms TTL=64
Hopefully there is a better firmware that doesn't suffer from this kind of performance degradation based on modem activity. if not, I think Cox needs to remove it from their list of supported devices so consumers like me don't make a dumb mistake and spend $120 + their own time trying to figure out what is wrong with it.