Jump to content

fatal0Efx

Members
  • Content Count

    29
  • Joined

  • Last visited

About fatal0Efx

  • Rank
    Apprentice

Basic Info

  • Gender
    Not Telling
  • DumaOS Routers Owned
    Netduma R1

Recent Profile Visitors

960 profile views
  1. I haven't had a chance to test yet. A reset will be fairly disruptive for me. I'll chime in when I get a chance.
  2. Reposting here as @Netduma FraserFraser thinks this should still not be an issue. To answer your questions I only had a single device active on it during my testing and it didn't matter if I gave all percentage to that device or just set it even for all. Shared bandwidth was turned on. As far as I could tell with the configs I tested (especially shared bw) , my device would have been expected to get 100% of the bandwidth but it barely got more than half. Nothing else was active to consume any bandwidth.
  3. @Netduma Fraser See my original post I created that you and Alex were helping with. I don't want to hijack this thread. It was just kind of left as a limitation of the R1, at least from Alex's pov.
  4. @Netduma Fraser Both you and Alex already worked with me on this in the past. Not sure what else you'd want to look at, but if you want to take a stab at it again see my OP on the matter.
  5. I wouldn't bank on that. I've recently discovered that the QoS feature alone prevents my R1 from getting my full 200 mbps down due to the 100% cpu issue. If I disable QoS I can get full speeds. That's with one device plugged into the R1 and it doesn't matter what QoS values are set. The R1 hardware simply cannot handle anything over 100 mbps well if certain features are used. Fwiw.
  6. Just an FYI about the speed drop, I've recently discovered that the simple use of QoS kills my R1 router with speeds over 100 mbps. I have 200 down, but found that I was being limited to 100 due to the 100% CPU issue, but if I disable QoS I get full speeds. As a test maybe you guys should disable QoS to see if it improves your PPPoE issues any.
  7. Thanks Alex. Of course do what's best for the product. I'm just antsy for some new great firmware!
  8. The question isn't whether the R1 devices will get the firmware before Netgear devices. Logistically speaking, that's likely going to happen. It's how much involvement (and associated delay) will Netgear have BEFORE it's considered ready for release on just the R1? Will Netduma release it to R1 before Netgear gets involved, or does Netgear have to fully certify it before it is even considered for release, even for the R1? I'm betting it has to pass through Netgear first, at least to some serious degree, before the R1 community will ever see it.
  9. That's what I was hoping. It's just the way it was said seems to suggest they're not even willing to release it to the R1 community (or promise an update at least) until Netgear first signs off on it, which concerns me as if Netgear is somehow going to dictate when this comes out even on the R1. That's what I was looking for clarification on.
  10. Does this mean the R1 will never get the firmware until Netgear does, like DumaOS itself? I thought the benefit of the R1 was that it would be able to get things first because you did NOT have to wait for the red tape with other vendors (like Google Nexus devices get the new Android before any third party). Or is that part of the Netgear deal that they get first dibs?
  11. Haha. I was totally kidding. I'm kind of the opposite. I like to fit as many things as possible on screen to multitask so need everything to be as small as possible while readable. OH well. I think I'd browser scaling working for all elements would probably go a long way. Either that or allowing us to simply customize all elements of the interface to our liking, from text sizing, to element/panel resizing, etc.
  12. You may not be the right person to talk to me about this issue. You're apparently a blind ol' bat haha.
  13. It looks like that may be the issue. With QoS disabled, the cpu hits about 50-60% (up from 20% nominal). First test after enabling QoS saw full bandwidth (interestingly), with CPU at 80%. Second test after enabling QoS went back to being throttled around 100 Mbps but CPU did hit 100% the entire time. Subsequent tests remain throttled and 100% cpu. Wonder how the first test was successful? Perhaps all QoS functionality wasn't fully enabled when I ran the test? Ultimately if this is truly a CPU issue, that's unfortunate as nothing can really be done I'd imagine, unless there are some potential room for improvement in the code base?
×
×
  • Create New...