rbowman <bowman@montana.com>: Dec 29 01:06PM -0700 On 12/28/2018 08:43 PM, nospam wrote: >> that part. The early Mac that was a cube was the only thing that could >> meet TEMPEST requirements. > the cube was a *long* time ago. Yes, it was. 1985, iirc. My end of the project involved the TI TMS9900 microprocessor. It had little going for it other than being one of the few radiation hardened devices at the time. The Macs were used for documentation and as I said were selected because they meant TEMPEST specifications. https://en.wikipedia.org/wiki/Tempest_%28codename%29 The Russkies were squatting out in the bushes, dontcha know. It's always the Russians. I doubt if they bothered to skulk around our bushes. https://en.wikipedia.org/wiki/1985:_The_Year_of_the_Spy > there's nothing wrong with focusing on consumer products. it's a *huge* > and *very* lucrative market, although apple is not solely consumer > focused. Certainly there's nothing wrong with consumer products. I've never worked in that sector, and hence have never been involved with Apple products. iPhones and iPads have started making some inroads as information delivery devices in my world. However the focus has been more on ruggedized devices, be they laptops or tablets. https://www.fieldtechnologiesonline.com/doc/the-ipad-vs-the-rugged-tablet-whats-what-0001 That is not a market Apple addresses and being a walled garden no third party can do so. End of the World Industries can make an Android tablet that will survive, but it better not start with 'i'. That said, personal devices are penetrating the workspace and if some cop prefers to use an iPhone we've got to deal with it. Sometime. It won't be me personally. |
nospam <nospam@nospam.invalid>: Dec 29 05:06PM -0500 In article <g8q2c0F78d6U1@mid.individual.net>, rbowman > >> meet TEMPEST requirements. > > the cube was a *long* time ago. > Yes, it was. 1985, iirc. no it wasn't. the cube was 2000-2001: <https://en.wikipedia.org/wiki/Power_Mac_G4_Cube> it was a tip of the hat to steve jobs' original next cube, which was announced in 1989 and shipped in 1990: <https://en.wikipedia.org/wiki/NeXTcube> in 1985, only the mac 128k and 512k existed, with the 512k/e in late 1985. the mac plus was released in january, 1986. > Certainly there's nothing wrong with consumer products. I've never > worked in that sector, and hence have never been involved with Apple > products. apple does more than just consumer, although that is definitely where they're strongest. > iPhones and iPads have started making some inroads as > information delivery devices in my world. However the focus has been > more on ruggedized devices, be they laptops or tablets. there's more to an iphone and ipad than information delivery. > That is not a market Apple addresses and being a walled garden no third > party can do so. End of the World Industries can make an Android tablet > that will survive, but it better not start with 'i'. nonsense. there are numerous ruggedized cases for iphones and ipads, with otterbox being the most well known. they're bulky, but they do withstand a *lot* of abuse. there is also no walled garden, a myth that will never die. here's one with a keyboard: <https://www.zagg.com/eu/en_eu/keyboards/rugged-book-keyboard-case> here's a screen protector that withstands hammering: <https://www.youtube.com/watch?v=Hsxl1bRTldo> <https://www.youtube.com/watch?v=RtMn79-hr9E> and there's even a bulletproof case: <http://www.marudai-corp.com/iphone-case/e-info-product.html> > That said, personal devices are penetrating the workspace and if some > cop prefers to use an iPhone we've got to deal with it. Sometime. It > won't be me personally. your loss. |
rbowman <bowman@montana.com>: Dec 29 03:54PM -0700 On 12/29/2018 03:06 PM, nospam wrote: > no it wasn't. > the cube was 2000-2001: > <https://en.wikipedia.org/wiki/Power_Mac_G4_Cube> Excuse me. Not being an Apple user I'm not familiar with the pet terms. https://en.wikipedia.org/wiki/Macintosh_128K To my eyes it looked like a cube. > in 1985, only the mac 128k and 512k existed, with the 512k/e in late > 1985. the mac plus was released in january, 1986. Precisely. The rather cubical looking Mac... > there's more to an iphone and ipad than information delivery. Yes there is. However all we are concerned with is delivering updated incident or dispatch information to emergency responders. If they want to play Angry Birds in their spare time, good for them. > otterbox being the most well known. they're bulky, but they do > withstand a *lot* of abuse. there is also no walled garden, a myth that > will never die. Obviously you didn't read the link. An iPad in an otterbox is NOT a ruggedized tablet. https://gizmodo.com/should-the-supreme-court-knock-the-first-brick-out-of-a-1830569176 You're right. The walled garden is the myth that will never die. The strategy has worked well for Apple so don't try to deny it. > your loss. Not in the least. |
nospam <nospam@nospam.invalid>: Dec 30 12:10AM -0500 In article <g8qc7aF9aqpU1@mid.individual.net>, rbowman > > the cube was 2000-2001: > > <https://en.wikipedia.org/wiki/Power_Mac_G4_Cube> > Excuse me. Not being an Apple user I'm not familiar with the pet terms. it's not a pet term. it was called a cube because it was actually a cube. it did have an acrylic casing to raise it off the table for cable management, however. it was also designed to *easily* be opened without any tools. flip it over, push in the handle to pop it out, then lift, giving full access to the internals, the very opposite of a 'walled garden'. <https://d3nevzfk7ii3be.cloudfront.net/igi/Pw6YRIHwmiDYUWTX.large> <https://d3nevzfk7ii3be.cloudfront.net/igi/2STkBEy42mB2okjN.large> <https://d3nevzfk7ii3be.cloudfront.net/igi/AuJkNVuB3RH4NjKl.large> > https://en.wikipedia.org/wiki/Macintosh_128K > To my eyes it looked like a cube. then your eyes need to be checked, along with a refresher on geometry. > > in 1985, only the mac 128k and 512k existed, with the 512k/e in late > > 1985. the mac plus was released in january, 1986. > Precisely. The rather cubical looking Mac... it did not look like a cube: <http://photos2.insidercdn.com/1125-128kmac-2.jpg> > Yes there is. However all we are concerned with is delivering updated > incident or dispatch information to emergency responders. If they want > to play Angry Birds in their spare time, good for them. angry birds is passe. even pokemon go is mostly passe. fortnite is where it's at now. > > withstand a *lot* of abuse. there is also no walled garden, a myth that > > will never die. > Obviously you didn't read the link. i did and it's bullshit. rugged means able to withstand extreme conditions and abuse. rugged does *not* mean encryption, tco and compatibility, what the article discusses. all ios devices are fully encrypted, can be remote wiped if necessary and centrally managed for large (or not so large) deployment, so that is not an issue. the article speculates that an ipad would overall cost more despite having a lower initial cost due to frequent failures, however, they offer with zero evidence to support that. it also incorrectly assumes that by the time an app is released, a newer incompatible ipad would be released, which is also wrong. the article was surprised that american airlines would choose ipads for the cockpit, something other airlines have also done since the article was written, due to their reliability and lower cost versus managing the paper it replaces. that alone contradicts the article's claims. it's also a 6 year old article which is even more incorrect now than it was when written. > An iPad in an otterbox is NOT a > ruggedized tablet. yes it is. rugged means it's able to withstand extremes and abuse, which is already pretty good but with an otterbox even more so. it does not mean encryption, tco or app compatibility. > 30569176 > You're right. The walled garden is the myth that will never die. The > strategy has worked well for Apple so don't try to deny it. that's not a walled garden, especially since the app store not the only way to install apps. nothing prevents anyone from writing their own custom ios apps for whatever purpose or hiring someone to do so if they lack the skills. there is no requirement to use the app store (which i explained in another post). there are a *lot* of custom corporate apps on ios that never see the app store. and let's not forget windows 10s, which *only* runs apps from the microsoft app store, making *it* the walled garden, not apple. game consoles also have very limited options for titles, also walled. having an app store with vetted apps is not inherently bad. it greatly reduces the amount of malware and other crap that people install, rending a system unstable and/or not secure. the malware vectors where one can pwn a windows system do not exist on ios. nothing is perfect and something could potentially slip through the cracks, but if it does, it's quickly removed from the store. in extreme cases, it can be uninstalled, something google has had to do on several occasions, while apple has not. in other words, ios software is 'rugged'. |
Jeff Liebermann <jeffl@cruzio.com>: Dec 29 10:41AM -0800 On Fri, 28 Dec 2018 21:52:56 +0000 (UTC), arlen holder >Ooma tells me speed & jitter are ok but I have 0.25% packet loss. That's actually very good, especially with an RF link. Interference from co-channel users usually produces some packet loss. Try a continuous ping test to your WISP's router or access point (so that you're only testing the wireless path). For Windoze, something like: ping -t ip_address_of_WISP Look for missing packets and longer delays, which are a sign of retransmissions, usually due to interference or collisions. For more accuracy, try Fping: <http://blog.perceptus.ca/2017/11/10/fping-windows-download-the-last-version/> The "PureVoice" feature may also be involved: <https://www.voip-info.org/ooma-telo/> To combat the packet loss that some VoIP users experience as garbled or interrupted voice signals, Ooma Telo's PureVoice HD also incorporates adaptive redundancy — the Ooma Telo VoIP home phone system detects packet loss and issues duplicate packets to cover the gap. >What happens, as a result, is that in any given phone call, the voice >drops, or is blurbled, for seconds at a time. That can be packet loss, but my guess(tm) is that it's jitter or packets lots in the Asterisk switch. >I don't quite understand how losing one packet in 400 on average is causing >that, but they said take it up with the WISP who has already said it's as >good as he can make it. It's not. Ooma does not tell you the end to end (POTS to your phone) packet loss. It only displays the packet loss between their servers and your Omma device. It does not show anything happening between the POTS line and the Omma servers, which can product garble, without showing any packet loss. >Ooma suggested a new cordless phone set. You old and new cordless phone does not do packetized data and therefore would not affect the packet loss. However, if the RF link in the cordless phone is defective or there is interference on the cordless phone frequency, then you would get garble from the cordless phone. Try testing the cordless phone at some other location with a POTS line, or temporarily replacing the cordless phone with a wired POTS phone. >you're happy with? The base MUST be a full phone (speaker + dialer + wired >handset) with as many cordless as is feasible (usually 2 to 4 come with the >set). I would say something about the included wireless handset that comes with some Ooma base units, but since you didn't see fit to provide the model you're using, I won't bother. >Ooma tells me packet loss should be 0% ... do you have a good test for >that? (Ooma didn't have a test we could run.) Google for "voip test" and you should find a variety of likely test sites. Try to find one that uses the same backhaul as your WISP or ask your WISP which VoIP test site they recommend. For example: <https://www.onsip.com/blog/what-your-voip-test-results-mean> <https://sourceforge.net/speedtest/?source=voip-info> <https://www.voipreview.org/speedtest> You'll also find a jitter test, which might be useful. Play with the codec selection on your Ooma phone. <https://support.ooma.com/home/star-codes-on-your-ooma-device/> Try iLBC (default) and G.711. -- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558 |
Jeff Liebermann <jeffl@cruzio.com>: Dec 29 10:56AM -0800 On Sat, 29 Dec 2018 10:41:10 -0800, Jeff Liebermann <jeffl@cruzio.com> wrote: ><https://sourceforge.net/speedtest/?source=voip-info> ><https://www.voipreview.org/speedtest> >You'll also find a jitter test, which might be useful. I forgot that Ooma has a speed test. It shows jitter, but not packet loss: <http://ooma.speedtestcustom.com> -- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558 |
arlen holder <arlen@holder.com>: Dec 29 10:33PM On Sat, 29 Dec 2018 10:41:10 -0800, Jeff Liebermann wrote: > That's actually very good, especially with an RF link. Hi Jeff, Thanks for your advice, as I'm also in the Santa Cruz mountains (other side of the hill from you) where WISP is the only thing in town (although Comcast threatens to bring up cable some day, which would put the small-guy WISPs like Dave & Brett at Surfnet, Loren at Hilltop, Mike at Ridge, and Bob at Etheric out of business in a heartbeat - all of whom I presume you know well). I'm on 5GHz with a 30dBi Rocketdish with a straight shot, mountain to mountain, of about 25 miles by road, but only a couple of miles (maybe two and a half to three miles?) air-to-air (which is what counts). The Ooma technical folks ran a probe, after trying to talk me into hooking the "modem" (I never tell them it's a transceiver because that just confuses them) directly to the Ooma box, where my Ooma box is hanging off the router. The telephone base is hanging off the Ooma box, and then I use hand helds around the house. The problem is mostly on the handhelds, but I can't imagine that they're causing the 0.25% packet loss that Ooma tech support measured. > continuous ping test to your WISP's router or access point (so that > you're only testing the wireless path). For Windoze, something like: > ping -t ip_address_of_WISP This is a good idea. I need to log it though, so I'm running a ping -t to an internal hop that I found using a tracert. Is something like that what you are suggesting? C:\> ping -t WISP_AP_IP >> ping.log > retransmissions, usually due to interference or collisions. For more > accuracy, try Fping: > <http://blog.perceptus.ca/2017/11/10/fping-windows-download-the-last-version/> I'll check that out, as if I find missing packets, that would explain where the problem lies. > HD also incorporates adaptive redundancy — the Ooma Telo VoIP > home phone system detects packet loss and issues duplicate > packets to cover the gap. Hmmmmm.... I'm not sure if I can tell that is kicking in or not, nor what to do about it if it does kick in. > That can be packet loss, but my guess(tm) is that it's jitter or > packets lots in the Asterisk switch. I'm not sure what an "Asterisk" switch is, where googling, <https://en.wikipedia.org/wiki/Asterisk_(PBX)> "Asterisk supports several standard voice over IP protocols". I guess it's part of the VOIP protocol that Ooma Telo uses...? > and your Omma device. It does not show anything happening between the > POTS line and the Omma servers, which can product garble, without > showing any packet loss. It happens on almost all calls, so, I'd "think" it's on my side. (But that's why I ask for debugging help.) > phone. Try testing the cordless phone at some other location with a > POTS line, or temporarily replacing the cordless phone with a wired > POTS phone. It _does_ seem to be better (less garbled) when I use the wired handset which is directly connected to the Ooma device. That diagnostic, alone, might indicate it's the phones. But do older (maybe 5 to 10 years?) Panasonic Costco phones cause garbling in and of themselves? And even so, as you said, they wouldn't cause 0.25% packet loss (they said the jitter was only 1ms where 20ms would be a problem, as I recall). > I would say something about the included wireless handset that comes > with some Ooma base units, but since you didn't see fit to provide the > model you're using, I won't bother. My bad. I apologize. It's a Panasonic KXTG6671 base plus a few Panasonic PNLC1017 cordless charger units spread about the home. It was a Costco thing, which, in reality, I never did like so I'm looking for an excuse to replace it. > <https://sourceforge.net/speedtest/?source=voip-info> > <https://www.voipreview.org/speedtest> > You'll also find a jitter test, which might be useful. Looking at your next post, I first tried this: <http://ooma.speedtestcustom.com> Which reported 3ms jitter, which was more than Ooma had reported <http://www.bild.me/bild.php?file=3773901ooma01.jpg> Pressing the "Again" button reported a 15ms jitter, which is huge <http://www.bild.me/bild.php?file=4418379ooma02.jpg> And, one more time, in sequence, gave me a 2 ms jitter: <http://www.bild.me/bild.php?file=4255229ooma03.jpg> Go figure. The 2ms is ok, but the 15 ms is at the limit, or nearly so. I also tried this nice suggestion of yours... <https://www.onsip.com/blog/what-your-voip-test-results-mean> Which seemed, by the GUI, to be EXACTLY the same as the Ooma test, only, for some odd reason, it picked New York to test against, where it came up with a 4ms jitter, even as it went across the country: <http://www.bild.me/bild.php?file=8371168ooma04.jpg> The second in the sequence came up with 4ms jitter: <http://www.bild.me/bild.php?file=2265190ooma05.jpg> And yet, the third, came up whoppingly high with 98ms jitter! <http://www.bild.me/bild.php?file=8194174ooma06.jpg> How is _that_ for lack of consistency! The Sourceforge site says it's "designed to test your current Internet connection speed for Latency/Ping, Jitter, Download Speed, Upload Speed, Buffer Bloat, and Packet Loss", which seems like a good test for me! <https://sourceforge.net/speedtest/?source=voip-info> Wow, those are detailed results, where the jitter was 4ms and the packet loss was a whoppingly high 4% as shown in the screenshot below. <http://www.bild.me/bild.php?file=3699166ooma07.jpg> Surprisingly, even with a 4% packet loss, the quality metric was 4.1 out of 5, which seems higher than it should be with such high packet losses: <http://www.bild.me/bild.php?file=9173143ooma08.jpg> And, just as surprisingly, they gave VOIP a checkmark in the summary: <http://www.bild.me/bild.php?file=2095808ooma09.jpg> Looking at that last suggestion, it seems to be an EXACT copy of the Sourceforge site where it came up with 4ms jitter & 0% packet loss: <https://www.voipreview.org/speedtest> But this doesn't show the same level of detail as did Sourceforge: <http://www.bild.me/bild.php?file=2921509ooma10.jpg> > Play with the codec selection on your Ooma phone. > <https://support.ooma.com/home/star-codes-on-your-ooma-device/> > Try iLBC (default) and G.711. Hey Jeff! Now that's interesting. Very interesting. I normally do a "*82" or a "*67" but I didn't know about the others. The first thing I tried was "*#*#001" which reported "240828". Kewl. Then I made a phone call using: *82*96-1-408-123-4567 which had decent call quality. I'll keep doing this "*96" stuff, which might be the cat's meow. Thanks. |
Rene Lamontagne <rlamont@shaw.ca>: Dec 29 05:11PM -0600 On 12/29/2018 4:58 PM, arlen holder wrote: > Approximate round trip times in milli-seconds: > Minimum = 1ms, Maximum = 2141ms, Average = 19ms > Control-C Trimmed all your shit, Ya dumb Prick |
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to sci.electronics.repair+unsubscribe@googlegroups.com. |
No Response to "Digest for sci.electronics.repair@googlegroups.com - 8 updates in 2 topics"
Post a Comment