38 new of 122 responses total.
Erm, that was Re #82 ;-)
Regarding #84; You know, I've never heard that before. Like I said, do you have a citation?
I'll have a rummage for one.
This is interesting: http://en.wikipedia.org/wiki/Kibibit They seem to use ``Kib'' or ``Kibit'' (with a capital K) instead of ``Kbit'' or ``Kb.'' They do acknowledge that ``kilobit'' can be either 2^10 or 10^3 depending on context.
This is also interesting: http://en.wikipedia.org/wiki/Binary_prefix Note that they say that in the SI system, `K' (capitalized) stands for Kelvin, as a unit of temperature, and `k' (lowercase) only stands for `kilo.' They say that outside of SI, K and k are mostly interchangable, and can refer to either 2^10 or 10^3, as I had originally said. To wit: 'The one-letter abbreviations are identical to SI prefixes, except for "K", which is used interchangeably with "k" (in SI, "K" stands for the kelvin, and only "k" stands for 1,000).' However, they do say that as of 2005, the binary meanings are deprecated.
k (as a multiplier prefix) should only ever be used to mean 1,000. Everywhere I've ever worked or studies, K has been capitalised to differentiate it from k. Telecomms people talk in terms of kbits/sec, and mean 1,000 bits. Computer people talk in Kbytes and mean 1,024. It's not rocket science ;-)
Here's an example of K from a PDP-11 manual... http://pdos.csail.mit.edu/6.828/2005/pdp11/pdp11-40-000009.html
Here's a KIM-1 manual from 1976... http://users.telenet.be/kim1-6502/6502/usrman.html
re #90: You're right that "it's not rocket science", but it's not universally or consistently applied, either, which means making assumptions based on the use of "k" or "K" is dangerous if you need better than approximate numbers.
It's been consistently applied in my experience, but it's true that a few people don't use it correctly.
Take a random sample of computer manuals, text books (I hope they're right!) or EPROM / SRAM data sheets. K = 1,024 is a long-standing convention.
Yes, but you were talking specifically about K = 1024 and k = 1000, and in neither of the two references that you posted can I find such a distinction. Everyone knows that most computer manuals refer to K as 2^10 = 1024. Your claim was that they also refer to k as 1000, which is not universal, and in fact, is a convention I've never heard of before, and is not supported by your evidence. If telecom people refer to kbits as 1000 bits, that's great, but what McNally says is true: if you want to be exact, you've really got to specify.
k is 1,000 because of S.I. (km, kg, kW etc.) It's only necessary to specify because some people seem underinformed.
*sigh* It's not being underinformed, Andy, it's recognizing that standards aren't universally followed. I don't know how to explain it better than that. Really, though, it's true: not everyone follows the same standards.
Never mind. Let's talk about wireless networking. My next wireless networking task is to find a PCI 802.11g adaptor that works with NetBSD. This could take a while.
How are you searching, in BSD online discussions?
I'll probably start with the man pages for common device drivers such as ath(4) and perhaps wi(4). Hopefully I'll be able to find a card that has an appropriate chipset.
There are lists of linux-compatible pcmcia cards. Why don't you search on BSD PCI wireless?
The man pages that I mentioned include lists of cards that are supposed to work. Sadly some manufacturers will change the chipset in a product without changing the model number so it can be something of a lottery.
Re resp:75: My impression is that the computer world pretty universally used K=1,024 until marketing types realized they could put a bigger number on hard disk packages if they used K=1000. For a while they tried to avoid confusion (and presumably false advertising claims) by using the phrase "million bytes" instead of "megabytes."
I never saw them use K=1,000, but I did see them use M=1,000,000 which makes sense in the context of S.I. They could have excusably used k=1,000 but I never saw that either.
I now have a D-Link DWL-G510 802.11g PCI wireless network adaptor working under NetBSD-current.
What module(s) and what else did you need to do?
I didn't use any modules, but I had to upgrade to NetBSD 4 which is not quite released as stable yet (it's in Beta testing). My kernel includes the ath(4) driver and for some reason that I'm not clear about yet, bpf (the Berkeley packet filter) was also required. I have to launch a thing called wpa_supplicant because the wireless network uses WPA, which is supposedly less insecure than WEP. The usual procedure for launching the supplicant didn't work for me, so as a temporary measure I launch it from the rc.local script. Hopefully that will be fixed before 4.0 is released.
It annoys me that some Linux distributions no longer have an rc.local script. There are some applications where creating a full SYSV init script is major overkill.
Do you include SATCOM in the list of wireless networking techniques/technologies? When I deploy in the wake of natural disasters, I am responsible for backhauling unclassified voice and data communications over a satellite link, as well as management and maintenance of the solution. -DTK
Sure! Sounds reasonable to me.
Probably like a less cool version of the rig your brothers took out to the mountains or the sandbox. -DTK
Re. #110: That qualifies. Is that done using VoIP or something else? It's telling that even though years have passed since I asked the question, adding a NetBSD host to a WiFi network is still awkward to the point where I tell people not to bother.
We use VoIP phones, connecting back to a phone switch at the HQ. The phones use lightweight codec-specific signalling, common to both the phones and the switch. Nothing terribly novel.
Is latency much of an issue with the satellite link or is that better with today's LEO birds?
We do not bounce off a LEO bird; they move too much. Instead, we bounce off of a geostationary bird. We set expectations about latency, and people adapt pretty quickly to the latency, as long as it is consistent. Jitter is your big killer, not delay. Oh, and SAA on Cisco gear, or SmokePing on UNIX (or Linux) is absolutely your friend, followed closely by any NetFlow analyzer you can cope with.
I'll ask the packet pushers what SmokePing is.
http://oss.oetiker.ch/smokeping/
resp:115 Latency is almost always an issue for satcom. Pushing on Ka or X band to geo-sync/geo-stationary is going to be slow because, well, the speed of light isn't just a good idea, it's the law. :-) I've never had great luck with LEO for anything. Maybe DAMA voice, but I don't recall what birds those were bitting.
Here here. GEOS is great for resilience, and as long as you can tolerate delay, you can go anywhere in its shadow. That said, it takes people a while to get used to the delays involved in a voice call, but as long as the delay is pretty consistent (i.e. low jitter), people adapt. Oh, and for the fans following along at home, remember that the speed of light in the atmosphere is a lot slower than the speed of light in a vacuum. I never tried using a LEO-provider; having to track a bird that is in motion relative to your frame of reference either requires the dish to be in constant motion, or accept drop-offs frequently. Neither seems like much fun, and not worth the small improvement in round-trip-time. -DTK
Indeed. It's a pain in the butt.
re #114 Back in the stone ages, we used analog phones through a multiplexer over VHF. VOIP is a very specific protocol overhead for packet node sites. I haven't looked at Network44 in years, though.
You have several choices: