Well, with everything the same, but using SFE instead of CTF, router has been up for 36 hours with no issues.
For now Ill attribute kernel panics to CTF.
Im suspecting that if @PaulGo uses ipv6 instead of ipv4, then I believe ipv6 completely skips NAT, so that could explain why he didnt see instability with CTF.
Joined: 01 Dec 2021 Posts: 289 Location: Maryland, United States
Posted: Wed Jun 22, 2022 21:08 Post subject:
A majority of the sites I visit are still IPv4. I would say less than 10 percent of the sites are IPv6. Also, unless your internet speed is above 400Mbps SFE works fine. I tested the R6300v1 using The Speedtest app on Windows 10 and with SFE the top speed was about 400Mbps. With CTF it is slightly over 700Mbps.
A majority of the sites I visit are still IPv4. I would say less than 10 percent of the sites are IPv6. Also, unless your internet speed is above 400Mbps SFE works fine. I tested the R6300v1 using The Speedtest app on Windows 10 and with SFE the top speed was about 400Mbps. With CTF it is slightly over 700Mbps.
Speedtest is not very good measurement for CPU saturation. Try downloading a 20GB file (Steam for example), and you will see it at 100% CPU with ~30% queue, which throttles to about 290Megabit with SFE. While speedtest shows like 50% CPU usage at 300Megabit. In other words, speedtest shows you max ISP throughput but not a good test for the router. If you do the same thing while using CTF you will see about 20% CPU utilization at full 300Megabit unthrottled.
the-joker wrote:
At this stage repeating same thing over and over is not going to change how either tech works or specific hardware.
Wink wink nudge nudge.
I know the saying, but what does it even mean in this context? Different things are being tried. This is the first time running for multiple days with SFE. So either there is a reading comprehension issue on your end, or complete miscommunication.
In the end of the day the point is to provide as much info as possible so that its useful to whoever stumbles upon this after we are all dead.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Wed Jul 06, 2022 8:54 Post subject:
After a discussion about the realities of development and related issues for both developers and users on another thread, I think its time to recap and see what is what.
@duxa has undeniably hit a scenario where the crashes happened, even if others with same router weren't having the same issues, this doesn't mean that the issue noticed doesn't happen.
It has been documented that the issue is reproducible 100% of the time By switching between SFE/CTF/SFE/CTF, without any other off default configs. Im not sure how under any normal circumstances this would be a real world scenario, but OK, a kernel panic was triggered none the less.
Critical: We still need a full serial log for this complete process as described above and not just arbitrary portions, because this will allow a full picture of the issue to be presented and let the developer decide what is or what isnt important in the log.
We dont know with any certainty that this is related to SFE or CTF or the kernel or DD-WRT itself handling code for switching/detection or if its router dependent, its too vague IMO so far, no one can blindly start re-writing code and needs an indicator where to start looking, otherwise its thousands of lines of code we are talking about if there's no starting point, right, lets be realistic about this? Who's got time for that, this is opensource and real life often gets in the way.