|
The current APs are also 254 clients capable, but this apparently does not mean that they guarantee bandwidth.
A 300Mbit/s device = 37Mo/s one direction = 18Mo/s both directions, so 254 devices would get with 100% efficiency about 70ko/s each, which is ... quite slow. 
But 18Mo/s for 8 clients is still about 2Mo/s/client, which should be sufficient for accessing a file or even watching SD videos from the internet, so I do not understand why I run into problems.
|
|
|
|
|
Bandwidth balancing certainly isn't built in to all access points.
This is a problem when using the hub model, clients are greedy, so when they receive a package they immediately send the next request allowing no room for other clients to use the bandwidth.
So if your AP doesn't have bandwidth balancing, it's the first to come that wins, the rest gets a timeout after some retries.
There are three solutions that I can see.
A) Get an AP with bandwidth balancing
II) Change the settings for TCP retries and/or timeout.
3) Block YouTube in the DNS.
|
|
|
|
|
Thanks, Jörgen, I'l ltry this  . Two of the four available APs can be configured.Jörgen Andersson wrote: lock YouTube in the DNS.
|
|
|
|
|
|
Here is another open-source monitoring tool: Cacti[^]
|
|
|
|
|
What do you see when you connect to the routers' admin page? Just those laptop connections, or everyone else in the place with a phone connecting to the free WiFi?
|
|
|
|
|
Only the laptops (and there is no free Wifi possibility - and even if, the Wifi is only activated when the cart is in use, so that would be a sporadic problem).
|
|
|
|
|
I've just found my first processor bug. No, not on one of the big guys like ARM or Intel but still a decent find on the Rabbit family of processors. The bug seems to have been there from the earliest days and to find it 20 years later is quite unexpected.
I've always said that I like programs you debug with an oscilloscope and hardware bugs you find with a test program, but this is the first bug on silicon and not at board level.
The feeling is quite ecstatic  (what a big nerd am I!)
Mircea
|
|
|
|
|
But isn't this like "It must be a compiler bug!"
|
|
|
|
|
Almost, but I have a hierarchy of esteem where at the bottom are software hacks (like me), compiler writers are some levels above and chip designers are almost at the top.
To find a bug so high up the food chain is exhilarating
Mircea
|
|
|
|
|
Most probably not. Test again and again ask yourself again and again is it really the processor and not your side. Most probably you will find it is your side, this from experience from my side 
[Edit]
Otherwhise you can name the bug
modified 27-Mar-21 21:01pm.
|
|
|
|
|
Quote: Most probably not. Test again and again ask yourself again and again is it really the processor and not your side.
I did and I'm fairly sure this is not the case. Filed a bug report and we'll see what happens. I don't have any qualms admitting my errors so I promise I'll post the "denouement"
Mircea
|
|
|
|
|
Good luck then
modified 27-Mar-21 21:01pm.
|
|
|
|
|
Mircea Neacsu wrote: I don't have any qualms admitting my errors so I promise I'll post the "denouement"
And if it turns out you were right, will we have to call you Mircea cel Mare?
|
|
|
|
|
Quote: And if it turns out you were right,
Unfortunately that's not the case. It was just my misreading of documentation as @Randor pointed out[^].
Anyway, as they say, the journey is more important than the destination and this one was a fun one
Mircea
|
|
|
|
|
Awesome!
Have you verified the "offense" on multiple samples of the chip?
|
|
|
|
|
Yes, on 3 generations of the chip: Rabbit 2000, 3000, 4000.
Mircea
|
|
|
|
|
A sand crab? Or maybe a sand flea? Cool.
modified 17-Feb-21 15:14pm.
|
|
|
|
|
Never found a processor bug, but not all USART chips were the same: one brand that the purchase dept found cheap only worked async, and failed horribly with synchronous data. Yeuch, but that was a git to find - my dev hardware and half the production stuff had the "good chips".
I remember finding my first compiler bug though: A Fortran problem on a GEC 4070 which generated the wrong machine code if the same variable was used in an IF and assigned in the next line of code. Joy when I worked out what it was and reported it to the ops manager. Who just said "yeah, we know about that one..." and left me feeling very flat.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
As Griff was saying:
Quote: Joy when I worked out what it was and reported it to the ops manager. Who just said "yeah, we know about that one..." and left me feeling very flat.
I worked it out what it is and here is my result.
Z80 processor has/had an instruction DJNZ that decrements register B and jumps if not zero. This is bread and butter of most small loops in Z80 assembly. It also has a set of "alternate" registers BC', DE' HL' but rather few instructions operate on those alternate registers. To compensate for this, Rabbit introduced an ALTD prefix that can be added to most instructions to make them operate on the alternate registers. Now what happens with the instruction ALTD DJNZ? Well, it takes the content of B register, decrements it and stores it in B' register making it a fairly useless instruction.
Of course, this is not documented in the manual and you have to figure it out for yourself.
Anyway, it left me feeling very flat
Mircea
|
|
|
|
|
The alt registers (or "shadow" registers) I always kept for interrupts (or NMI when we used that) so we could work faster - memory access to stack the registers is a load slower than EXX which was only 4 T states, compared to a minimum of 11 (plus any memory wait states) for a PUSH.
With a 4MHz processor, you shaved T states where you could!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Looks documented to me. The ALTD flag only changes the destination.
Mircea Neacsu wrote: it takes the content of B register, decrements it and stores it in B register
I believe what is actually happening here is that the ALTD instruction is setting the destination of the DJNZ operation to one of the "alternate" registers which leaves the B register unchanged.
Best Wishes,
-David Delaune
|
|
|
|
|
You are right; I should have paid more attention. However, it seems to me that it drastically reduces the usefulness of the instruction.
Mircea
|
|
|
|
|
Mircea Neacsu wrote: You are right; I should have paid more attention.
Too bad you didn't find a cpu bug. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Mircea Neacsu wrote: However, it seems to me that it drastically reduces the usefulness of the instruction.
Of course, more registers are almost always better!
Best Wishes,
-David Delaune
|
|
|
|
|
Quote: Too bad you didn't find a cpu bug.
Well the chase was exiting 
Mircea
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
