Hi Dan et al, See below.
El 23/03/16 a las 15:52, Dan Smith via chirp_devel escribió:
Yes, good to know about the performance issue. Also how can I measure that performance impact to compare for future improvements?
It's just a general thing: making lots of syscalls for very small bits of data is inefficient, and it means you're more likely to be blocked on the kernel during periods of high load (which you're contributing to). It's far more expensive to make a syscall than a regular function call. Also, with the tight timing you've got going on here, it could definitely cause you to miss another deadline you're expecting to make and manifest itself as instability under load and other varying conditions.
Make sense.
Most of the time we got reads with not the amount of data we must have and the driver failing, the other alternative was to use big time.sleep() here and there and we have then a long delayed reads and uploads with occasional resets of the radio.
Right, you can never depend on a read returning the whole thing you're expecting for. That's why you may need a queue which always reads as much as the radio has available, from which your code processes the frames as soon as they are whole.
I get the idea, and have a kind of schema in mind that may work even with bad read recovery to protect me from the radio miss behaviors.
Okay, but we could just separate them out in the model list. A user may not know if they have a v1 or v2 radio, but if you call them out like that, they can try both and then continue to use that one in the future. Making people with radios that aren't first in the list wait many multiples of 5 seconds is not reasonable, IMHO.
I was searching the net about this and most sellers have a "(Gen 2)" or something like that in it's advertising but the actual radio have no evident marking of the generation or version (at least in the advertised pictures)
Also the comments on the end of the file before the radio declarations is not accurate and has a lot to do with the former strategy, the only element that has a real impact now in the ident schema is the self._magic list now. This has been corrected in the draft version, sorry for that.
So it makes sense to separate radios from just one family in the listing and tag it as "Gen 2" for example, only if hey have so many magics to try for all members in that family.
Looking the data we have now I realize that we only have one case of this with a family of radios with two magics to try (BTECH UV-5001), with just one UV-5001 Gen 2v2 with a different magic from the other 4 members of the family.
As pre-production and alpha units never got into the market, we only have the 1st, 2nd & 2nd ver 2 generation on the street and being just this last the only that need a different magic there is a chance of just 33% of getining the wait on the radio ident.
That's just about 6-7 seconds of wait on the ident before the clone start if you have that radio (just 33% chance), and also the progress bar will be moving all time to show you progress.
IMHO that's not a big issue, so I vote for keeping it in the actual way as long the count of magics in the list don't climb higher. I have already a note in the driver about this to make the changes if the issue get complicated in the future.
Well, first thing this morning there was already a bug about timing issues:
You are right, the description of the issue has much to do with what you have mentioned about system load.
No, this value is NOT mutable.
This radios has a REAL mem span of 0x4000 (you can safely read up to there, and write too) but in the read the OEM software get just up to 0x3200 (we get full span in chirp) and in the write just up to 0x3100.
We respect the write boundary and this driver will never write beyond 0x3100, see _upload() procedure comments
Okay, in previous models, there was a reserved region at the end which appeared to be immutable, until we found an extra tool that let a vendor customize what was in this last block...
Then this will be a real mess...
I was today inspecting the ident code and it's constructed with data from that region exclusively and the only "non mutable" and unique data for every radio is the one we use now as fingerprint.
Was the fix to the problem you mentioned?
To learn from it.
If the JetStream is a clone of this (or vice versa) get support for it is as fast as Jim can get it on it's hands to test it and we will work on that direction ASAP.
David Fannin has the radio already and will be looking into the changes needed for this. I'm hoping he'll also be able to help with some of the stability issues.
Thanks Pavel and Jim!
Ok, I wait for David to write me an email to give him a welcome to the team and exchange ideas/code/etc.
Thanks for taking the time to coach me on this. I have a lot of "homework" to don now.
73.