|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
Well, I finally replaced the the 10+ year-old SuperMicro motherboard and dual Pentium III processors in my file server.
It's hard locked twice in the last month, so I figured I'd give it some modern hardware:
Yes, the video card is overkill, but it was only $40, and the other Intel motherboards with onboard video were a bit more expensive.
Normally, this wouldn't warrant a blog entry, but I think I just upgraded the oldest computer (motherboard, CPU, memory) I've ever owned. Let's take a trip down memory lane…
Back in the summer of 2000, high school graduation presents and other things gave me a few dollars to spend on new computer equipment that I could take with me to RPI in the fall.
I ended up picking up a full-height SuperMicro case, motherboard, and processors. The motherboard was the SuperMicro P6DBU Intel 440BX and the processors were 2x Intel Pentium III 800MHz units w/the coppermine cores. It was hot stuff back then, let me tell you. I forget how much memory the system started off with, but it was at least 256MB.
Here's the earliest photo I could find of the system (sorry, Sony Mavica quality):
The P6DBU board was a server motherboard, and had an Ultra2 SCSI controller on-board. For awhile I ran a Western Digital 10k RPM SCSI hard disk, but that eventually accumulated a host of bad sectors, and was way too loud, for some reason.
The SuperMicro case was really huge. It was pretty bulky, too, and designed fairly badly. My roommate back in my freshman year at RPI ended up purchasing the same case, and hating it as well. Oh well.
The machine [named taco] started out with Windows 2000. Back then I knew nothing about FOSS, Linux, or much else, actually. I think the most CPU-insitive application I ran was Quake III Arena (and I was fairly good, for a time).
In 2003 (I think) the machine was upgraded to Windows XP and eventually made its way up to 1GB of [ECC] RAM, the maximum the board could take. Along the way, some of the RAM went bad, and needed to be replaced. I think this is when I replaced it all with Crucial memory. For some reason I took a photo of the memory replacement in-progress:
In 2004, after graduating from RPI, I repurposed the machine as a file server running Debian GNU/Linux in the basement of my parents' house in New Jersey. I renamed it atlantis (for no apparent reason) and threw a few miscellaneous hard disks in a JBOD setup with Linux's LVM. According to IRC logs, the JBOD size started at 720GB (2x 120GB, 1x 400GB, and 1x 80GB). Here's what it looked like back then:
When I moved to Charlotte in 2005, the machine came with me, retaining its role along with the addition of DHCP and DNS servers (and later Asterisk PBX).
In August of 2006, I shuffled around the JBOD to provide 1520GB of storage by adding and replacing some disks. In March of 2008 I decided that JBOD was probably a bad idea, and picked up 3x 1TB WD disks, to replace the JBOD with some RAID-5 (w/LVM on top). Unfortunately, during the upgrade, the JBOD died. Here's me whining on IRC about it:
2008-03-30T12:11:47 -0400 < prox> Nice. My JBOD array just blew up.
2008-03-30T12:11:52 -0400 < prox> There goes 668GiB1
2008-03-30T12:13:32 -0400 < prox> Time for some LVM on top of RAID-5.
2008-03-30T12:19:22 -0400 < silencer> aw
2008-03-30T12:21:40 -0400 < prox> Yeah, and it died just as I was decommissioning it.
2008-03-30T12:22:08 -0400 < prox> Got 3x 1TB WD disks, and was copying stuff from the old array, and then _bewm_.
2008-03-30T12:23:53 -0400 < bleh> What huh how?
2008-03-30T12:24:08 -0400 < bleh> Oh, the old one.
2008-03-30T12:24:16 -0400 < bleh> Eek.
2008-03-30T12:24:38 -0400 < prox> The old array consists of: 1x 120GB, 1x 250GB, 1x 400GB, and 1x 750GB.
2008-03-30T12:24:40 -0400 < prox> The 400GB died.
I had to restore lots of stuff from optical backups, some of which didn't work. I lost quite a bit of TV shows. At least the new array would be redundant (and is still functioning).
Around that same time, I upgraded the case and power supply in atlantis to some Antec hardware with some nifty new blue LEDs:
Fast forward to the present, now the P6DBU is desommissioned, and maybe the motherboard and processors will make their way to my living room. I still have the original SuperMicro case in the closet. It's in great condition! I suppose I'll have to bring it to a recycling place, soon.
Anyway, thought I'd share that. The P6DBU, processors, and memory lasted over 10 years! Interestingly enough, the motherboard was manufactured in the United States! I bet that's hard to find these days.
It's been awhile since I've blogged anything, so here are some updates.
dax is the FreeBSD server that powers this website, and routes IPv6 traffic for my network. I bought a new server from the nice folks at Voxel in the hopes that it would fix the instability that I've had to deal with over the past 2-3 years. Unfortunately, while the new server is quite fast, it still suffers from the same instability. There's no doubt in my mind that it's a serious FreeBSD bug. Can it be reproduced? Nope. Do I know what's causing it? Nope. Yeah, that means it'll probably never be fixed.
Anyhow, the new server has some nice specs.:
I don't really use the GigE to even a fraction of its potential, but it's still nice to have for those oh-so-fast file transfers every once and awhile.
So far, 2010 has been a very stressful year at the office. I've been put in charge of quite a few projects, and I've had to say "I don't have time for…" way too often. Although, I'll take projects over being on call, any day. I don't miss that about my old position on the operations team, not one little bit.
Although I'm not the lead on the project, one of the big ones that's made some headway is a national IPv6 deployment. Our department has been given four bits shy of an ISP allocation, and I've developed a hierarchical addressing plan that is flexible and precise. Utilizing more than half of the block we've been given, the plan allows for unimaginable growth as well as offering the ability to pinpoint the exact location (down to the floor in any building!) of a particular address. Well, if everyone uses it that way, then it'll work. The routing design I developed for IPv6 is also much simplified compared to its IPv4 sibling.
The plan is to deploy IPv6 nationally across the network by the end of 2010, and hit a few users and servers along the way. I think it's doable, but time is certainly short.
I managed to snag the JNCIE-M certification at the end of September. It basically means I probably know how MPLS works, and can configure routers to forward packets.
I just noticed that the paper has the old logo, instead of the new one. I like the old logo better, anyway.
I'm a little surprised I passed, but considering everything I had configured was working five minutes before the end of the exam, I guess I'm not too surprised. Supposedly I'll get a plaque in a few weeks. I guess I'll keep that at my desk at work.. or maybe not, because then everyone will keep asking me Junos questions.
Let's see, what else?
Well, I'm getting over a cold. I had to take Thursday and Friday off, since I was sneezing my head off, and didn't want to infect anyone. I ended up working the majority of both days from home, though, since there were meetings I couldn't afford to miss, a boatload of documentation that needed writing, and some Perl scripts that needed modifying before Monday.
This prompted my boss to send me an e-mail:
Ok no problem, feel better Mark. By the way, for most people, taking a sick day means that they will stay at home and rest, not work. ;). Hope you have a great weekend and feel better soon!
Well, Monday would have been unbelievably painful if I hadn't worked. Such is life.
I finally fixed all of my Twitter applications to use OAuth. Finally.
What else.. I picked up yet another Juniper SRX210 on eBay, so I could play with the chassis clustering (HA) feature.
It's still a bit clumsy, even with Junos 10.3, but seems to work as advertised. At least I don't get "Scheduler Oinker!" errors anymore when the fabric comes up.
Lastly, between every other fueling, I've been trying to see how high I can get my fuel efficiency, when driving around Charlotte in my non-hybrid vehicle. I've come up with the following for my driving moods:
By "old lady" type of driving I mean going the speed limit, accelerating very slowly, and driving without the windows open if I'm on the highway (does this really help?). It's really annoying, since I can't drive in the passing lane at all. I don't think I'm doing too badly, considering the engine is rated for 21 city and 30 highway. My "driving around Charlotte" essentially consists of me driving to work, to the pool, then home, every weekday. On weekends, it's usually miscellaneous errands.
And, I think that's it!
I came across the Withings Wi-Fi Scale on ThinkGeek awhile back, but only recently decided to purchase it. Over the past few months, I've (on & off, I might add) been keeping a record of my mass each morning, using a piece of paper and pen, then transferring it to digital form when it seemed necessary. I figured a change was needed.
The Withings scale was easy to setup, but only afterwards did I realize I'd be forced to use a crappy Flash-based web portal (or iOS app.) to view reports and graphs on my mass, BMI, and body fat. However, I was able to hack the communication between the scale and the web portal, and actually keep track of the data myself.
I'll try to describe the process I took, without getting into too much detail.
Let's start from the beginning. I received the Withings scale in a rather huge cardboard box. I'm not sure what ThinkGeek was smoking, but the size of the scale (in its box) was fairly tiny compared to the person-sized cardboard shipping container it arrived in. I opened the box to find no manuals, just a USB cable, batteries, the scale, and a single sheet of paper that directed me to the Withings' web site to sign up and setup my scale.
This is where I started worrying that I might have to use a web portal to view things, but I kept going anyway. The site instructed me to plug in my scale via USB, and then download an installer executable. Strangely enough there was one for Linux, so I grabbed that one, and used it to setup the Wi-Fi connectivity. It also did a firmware upgrade, supposedly.
I logged into the web portal, and.. yep, Iceweasel crashed instantly. Honestly, that's rare for me, so I had to use Windows 7 in the meantime (turns out it was time for me to ditch the amd64 build of the Adobe Flash 10.0 plugin, and upgrade to 10.1 w/nspluginwrapper). After filling out my name, nickname, current mass, height, age, and sex, I tried out the scale. The LCD display lit up as I stood on it. After a few seconds of repositioning myself with the aid of the arrows that lit up on the screen, it displayed my mass and then BMI.
The web portal accurately reflected these values, with the exception of body fat, which I figured would show up after a few more data points.
The web portal was clunky, and generally difficult to use. To make matters worse, it was horribly slow. Sometimes it would take 10-20 seconds for the points to display on the graph.
Irritated by the sluggishness of the web portal, I did a trace to my.withings.net, and a whois on the associated IPs (88.191.98.77 and 88.191.97.104):
[...] 4 paix-ny.proxad.net (198.32.118.197) 0.576 ms 5 londres-6k-1-po103.intf.routers.proxad.net (212.27.58.205) 81.819 ms 6 bzn-crs16-1-be1102.intf.routers.proxad.net (212.27.51.185) 82.700 ms 7 dedibox-2-p.intf.routers.proxad.net (212.27.50.162) 82.367 ms 8 88.191.2.57 (88.191.2.57) 82.428 ms 9 s1.withings.net (88.191.98.77) 82.162 ms inetnum: 88.191.3.0 - 88.191.248.255 netname: FR-DEDIBOX descr: Dedibox SAS descr: Customers descr: Paris, France descr: NCC#2007023902 remarks: trouble: Information: http://www.dedibox.fr/ remarks: trouble: Spam/Abuse requests: http://www.dedibox.fr/abuse/ remarks: trouble: Spam/Abuse requests: mailto:abuse@support.dedibox.fr country: FR admin-c: ACP23-RIPE tech-c: TCP8-RIPE status: ASSIGNED PA mnt-by: PROXAD-MNT source: RIPE # Filtered
Well, that's why it's slow. It's in Paris, in addition to the Flash content. It's also hosted at a dedicated server provider, Dedibox (now online.net?), which is well-known for cheap hosting solutions (that usually means it's crawling with botnet controllers and warez).
I then took a tcpdump of the traffic from the scale, and found that it was talking to another destination in that same network range, scalews.withings.net. [88.191.224.77]. In fact, the communication wasn't encrypted and fairly basic. After following the TCP stream with Wireshark, I figured out the basic order of operations:
For your viewing pleasure, the entire conversation can be found here. As with the rest of the stuff I'm posting here, don't think I've kept all the values intact.. I'm not an idiot!
The first thing that jumped out at me was that the server runs Ubuntu, and spills all of its version information. Apache 2.2.8, PHP 5.2.4-2ubuntu5.10. Jeez, 5.10 uh.. "Breezy Badger" is back from 2005! I'd say they need to upgrade.
The 4x HTTP POST requests are pretty simple:
POST /cgi-bin/once: Sending a simple "action=get" apparently just asks the server for a random ID or cookie value. It returns back this value along with a status (0, which apparently is equivalent to "no error"). I don't think the scale cares if it gets the same one every time.
POST /cgi-bin/session: The scale then sends an "action=new" along with the MAC address of the scale, an MD5 hash, firmware version, battery level, and two other values that I haven't been able to figure out (duration & zreboot). The server then responds with a larger JSON-encoded string:
{"status":0,"body":{"sessionid":"546-4c818c8e-3b918091","sp":{"users":[{"id":101010,"sn":"PRX","wt":66.3,"re":565,"ri":2337,"ht":1.7,"agt":30.2,"sx":0,"fm":1,"cr":1283558096,"att":0}]},"ind":{"lg":"en_GB","imt":1,"stp":0,"f":0,"g":97973},"syp":{"utc":1283558546},"ctp":{"goff":-14400,"dst":1289109600,"ngoff":-18000}}}
Let's go what I've been able to figure out of the values, here:
POST /cgi-bin/measure: This is the good stuff. The scale then POSTs a whole bunch of data that we care about:
action=store&sessionid=546-4c818c8e-3b918091&macaddress=00:24:e4:ff:fc:01&userid=101010&meastime=1283558512&devtype=1&attribstatus=0&measures=%7B%22measures%22%3A%5B%7B%22value%22%3A66850%2C%22type%22%3A1%2C%22unit%22%3A%2D3%7D%5D%7D
The real JSON of the values looks like this:
{"measures":[{"value":68950,"type":1,"unit":-3},{"value":583,"type":2,"unit":0},{"value":2292,"type":3,"unit":0}]}
Apparently, though, not all measurements may be given. I think sometimes the scale can't determine bioelectrical impedance (the re & ri values), if the user is wearing shoes (duh).
POST /cgi-bin/session: The scale just deletes the session it had, here.
So, certainly hackable!
So, my first thought was getting the scale to talk to one of my webservers instead of scalews.withings.net. Easy enough! A few lines in the named.conf of my local DNS cache and a small zone file did the trick:
// Withings
zone "scalews.withings.net" {
type master;
file "/etc/bind/prolixium/scalews.withings.net";
};
Zone file:
$ORIGIN .
$TTL 3600 ; 1 hour
scalews.withings.net IN SOA atlantis.prolixium.com. hostmaster.prolixium.com. (
2010091101 ; serial
7200 ; refresh (2 hours)
1800 ; retry (30 minutes)
1209600 ; expire (2 weeks)
3600 ; minimum (1 hour)
)
NS atlantis.prolixium.com.
A 10.3.4.6
atlantis is my local DNS server and 10.3.4.6 is the webserver (dax) I want scalews.withings.net to resolve to.
destiny% host scalews.withings.net. scalews.withings.net has address 10.3.4.6
Good enough! I then wrote a Python script to respond to each of the queries, store the bioelectrical impedance, mass, timestamps, MAC address, and battery levels in a MySQL database. It took a little bit to get everything working right (mostly fighting with Python modules), but I eventually got it returning responses that made the scale happy.
Rather than creating a bunch of separate Python scripts, I just made symlinks to the various URLs that receive POST requests:
lrwxr-xr-x 1 root wheel 11 2010-09-11 17:19 measure -> withings.py lrwxr-xr-x 1 root wheel 11 2010-09-11 17:19 once -> withings.py lrwxr-xr-x 1 root wheel 11 2010-09-11 17:19 session -> withings.py -rwxr-xr-x 1 root wheel 3983 2010-09-11 22:02 withings.py
The MySQL schema looks like this:
CREATE TABLE `measure` ( `sourceport` int(11) DEFAULT NULL, `sourceip` varchar(15) DEFAULT NULL, `mac` varchar(20) DEFAULT NULL, `battery` int(11) DEFAULT NULL, `firmware` int(11) DEFAULT NULL, `id` int(11) NOT NULL AUTO_INCREMENT, `recvtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; CREATE TABLE `value` ( `value` int(11) DEFAULT NULL, `unit` int(11) DEFAULT NULL, `type` int(11) DEFAULT NULL, `id` int(11) NOT NULL AUTO_INCREMENT, `measid` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `measid` (`measid`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1
I tested it for a bit, and realized that sometimes the scale won't send the measurements to the server after every step on it. I'm not sure why, maybe it's a bug - it'll queue it up and then send two POSTs to /cgi-bin/measure on the next connect. Also, it seems very inconsistent on whether it'll actually report the bioelectrical impedance, or not. Even barefooted, it seems hit or miss.
Also, I think that my script isn't perfect, or it's sending some wrong values to the scale, because sometimes my BMI is 99.9, which means I'm as big as a house, or something:
Also, because I have this love affair with MRTG, I wrote another Python script to provide MRTG with a snapshot of the last reported values (mass, battery, re, ei) to store in a couple RRDs. Here's the graph for mass (via drraw):
You can grab all of my scripts from here. To use them, make sure you change the variables (MySQL credentials, user profile, etc.) and the MD5 hash value and cookie returned from the "once" script. They may be related, and the values in the scripts are just examples, they will not work most likely. This means you'll have to do a packet capture yourself. Sorry.
The scale itself takes 4x AAA batteries, and eats them like crazy! It came with 4x off-brand batteries that were depleted after the initial setup and about 10-12 measures. I replaced them with some Energizer "advanced" lithium batteries, and it seems to now only decrease by 2-4% for every measure. Still quite a hog, considering it's only on for a few seconds during and after the measurements.
I wish the top of the scale wasn't a mirror. It feels like glass, and is very reflective, so any footprints mess with my OCD.
I'm a little worried that this thing is going to do an automatic firmware upgrade on its own, and break the scripts. Watch out for it! Maybe applying a firewall rule to the scale would be a good idea to prevent such things from happening.
I created a live dashboard of the data I've been graphing. Yeah, my mass seems to fluctuate quite a bit…
Although most of the time my schedule is fairly predictable, every couple days I'll shift things around and come home from the pool (or directly from work) at a different time of the evening. This, unfortunately, prevents me from creating an accurate program on my thermostat to manage the HVAC system in my condo.
I've been searching around for a decent Wi-Fi thermostat for awhile, now. I'd like to be able to control the heating and air conditioning remotely. My requirements appear simple, but apparently they're not:
I can't find anything that meets even half of these requirements!
The best I've seen so far both look really nice and sport some good features, but require management of the thermostat via a web interface running on the manufacturer's servers. Yeah, this means that all the thermostat does is create an outgoing connection to some external server and wait to receive commands. Become a statistic and give some external party access to the HVAC system and current temperature of my condo? No thanks! I want something that I can manage directly via my local network (or VPN).
So, right off the bat, these get bumped from the list:
Some of the above (I'm looking at YOU, Carrier!) even charge a recurring fee for access to the web portal functionality. Despicable!
Any ideas? Am I going to have to build my own with a microcontroller?
I had a chance to try out one of the new Sierra Wireless IntelliGo mobile Wi-Fi hotspots from Road Runner Mobile, today. The Wi-Fi hotspot is actually just a little router with WiMAX, CDMA (EV-DO), and Wi-Fi radios. The WiMAX radio represents one of the two so-called 4G cellular technologies, the other being LTE.
The Road Runner Mobile service provided by Time Warner Cable is actually Clearwire's WiMAX service, which falls back to Sprint's EV-DO network (3G) when WiMAX isn't available. It might fall back to 1xRTT, too, if 3G isn't available, but I had no easy way of testing this (well, without driving deep into South Carolina).
To set the stage, I can currently get around 2.7Mbps (megabits per second) with 79ms of varying latency on AT&T's UMTS network on a very good day.
For testing, I used wget to this URL and ran MTR to dax.
I first tried powering up this thing in my condo, and after what seemed like over 90 seconds of staring at the bootup logo, it started up.. but on Sprint's EV-DO network (at 80% signal strength)! I ran my tests anyway, and peaked around 1.3Mbps but averaging around 640Kbps. Latency sucked:
HOST: six Loss% Snt Last Avg Best Wrst StDev 1. foobarz.lan 0.0% 8 1.7 2.7 1.5 10.2 3.0 2. 68.28.249.69 0.0% 8 124.7 264.0 124.7 463.1 127.0 3. 68.28.249.91 0.0% 8 135.8 258.7 127.8 451.9 117.1 4. 68.28.251.54 0.0% 8 154.9 265.8 147.8 455.1 121.1 5. 68.28.255.9 0.0% 8 173.9 262.9 135.3 449.9 118.2 6. ??? 100.0 8 0.0 0.0 0.0 0.0 0.0 7. 68.28.253.69 0.0% 8 134.1 236.0 124.6 419.1 107.7 8. sl-crs3-fw-0-1-3-0.sprintlin 0.0% 8 169.0 229.2 122.0 383.1 85.1 9. sl-crs1-fw-0-7-0-0.sprintlin 0.0% 8 141.2 228.7 125.8 379.7 101.2 10. sl-st21-dal-1-0-0.sprintlink 0.0% 8 128.4 236.8 128.4 377.6 94.6 11. dls-bb1-link.telia.net 0.0% 8 132.3 214.7 129.1 319.1 72.3 12. atl-bb1-link.telia.net 0.0% 8 229.4 256.4 170.0 447.0 87.0 13. ash-bb1-link.telia.net 0.0% 8 240.5 272.1 173.7 449.7 109.7 14. voxel-ic-129445-ash-bb1.c.te 12.5% 8 192.0 259.2 167.7 418.9 104.3 15. 0.te6-2.tsr1.ewr1.us.voxel.n 12.5% 8 176.8 276.4 165.7 525.4 124.9 16. 842.te1-7.csr2.lga6.us.voxel 12.5% 8 168.0 297.1 168.0 607.8 145.9 17. dax.prolixium.com 12.5% 8 203.5 277.2 181.6 558.1 132.8
I had to toggle the option in the web interface to force the unit to only use 4G service. Only after I did this, it barely got a WiMAX signal and got me online. The web interface indicated I had poor signal strength at -88dBm (it rated this at 10% - I guess this is why it automatically picked 3G initially), and I agreed. I could only get roughly 360Kbps and the latency was all over the place:
HOST: six Loss% Snt Last Avg Best Wrst StDev 1. foobarz.lan 0.0% 8 1.6 2.1 1.6 3.1 0.5 2. 71-23-64-2.clt.clearwire-wmx 12.5% 8 276.1 190.1 87.4 485.0 144.0 3. 71-22-7-161.clt.clearwire-wm 0.0% 8 211.2 289.6 111.3 703.8 216.9 4. 66-192-62-1.static.twtelecom 12.5% 8 85.4 316.1 85.4 673.8 225.5 5. ash1-pr1-ge-2-0-0-1.us.twtel 0.0% 8 265.2 266.7 95.9 574.1 183.7 6. 0.te6-2.tsr1.ewr1.us.voxel.n 0.0% 8 155.2 231.1 81.1 474.5 126.4 7. 842.te1-7.csr2.lga6.us.voxel 0.0% 8 125.2 200.7 125.2 374.8 79.8 8. dax.prolixium.com 0.0% 8 124.6 167.3 98.2 297.7 76.1
DNS is slightly intercepted on the IntelliGo, since the PTR record for 192.168.0.1 was translated to $my_ssid.lan. No, foobarz is not my real SSID.
After driving around Ballantyne a little bit, I managed to figure out which tower was providing the WiMAX coverage for the area. It ended up being the one near Toringdon that's easily seen from I-485. I got the signal strength up to -47dBm (80%) by sitting in a parking lot of one of the office buildings in the area:
I could have gotten closer by walking across the grass, but I figured the orientation of the antennas would result in worse signal strength as I got closer. Oh, maybe I was just lazy.
I managed to peak at 6.76Mbps down, while the transfer rate typically hovered around 5.5Mbps. Latency was a little better, too:
HOST: six Loss% Snt Last Avg Best Wrst StDev 1. foobarz.lan 0.0% 8 1.7 6.0 1.7 18.2 7.3 2. 71-23-64-2.clt.clearwire-wmx 0.0% 8 66.1 78.1 65.3 94.4 12.4 3. 71-22-7-161.clt.clearwire-wm 0.0% 8 76.0 77.1 61.1 97.6 12.2 4. 66-192-62-1.static.twtelecom 12.5% 8 65.8 69.7 50.9 92.2 12.1 5. ash1-pr1-ge-2-0-0-1.us.twtel 0.0% 8 80.7 84.3 79.8 97.2 5.5 6. 0.te6-2.tsr1.ewr1.us.voxel.n 0.0% 8 85.6 90.7 74.8 107.6 10.0 7. 842.te1-7.csr2.lga6.us.voxel 12.5% 8 60.7 82.5 60.7 102.9 17.0 8. dax.prolixium.com 0.0% 8 86.5 92.7 82.1 105.9 9.9
Although not shown above, I managed to get one response back from the second hop (the other end of the PPP connection, no doubt) in 40ms. Supposedly LTE's RTT is in the 30s, so this certainly comes close!
Stopping at different points around Ballantyne with an average of around -57dBm got me between 3-4Mbps. Not too bad, but not that big of a jump over AT&T in the middle of the night (ie, no iPhone users).
The IntelliGo device itself is slightly disappointing. Battery life on the unit dropped to around 50% after 50 minutes of moderate use. The startup time before even starting the initialization of the radios is way too long (I mentioned 90 seconds earlier, but it could have been longer). Also, I don't know if it's just a result of the high frequency used by WiMAX (>2GHz) compared to other mobile networks or a problem with the IntelliGo itself, but I was disconnected left & right when driving and moving around. The kicker was hearing a beep (it makes certain noises for connecting & disconnecting from the mobile network, and when clients connect) consistently when I drove under overpasses!
In conclusion, I probably wouldn't buy one of these, but I don't travel too much, either. It's probably great for Internet access at airports and other public places where Wi-Fi is either not free or terribly congested.. as long as you've got WiMAX coverage, which doesn't seem to be too widespread, yet. Sprint's 3G isn't too shabby, though, but still pales in comparison to the speeds and latency of AT&T's UMTS network, even when congested with iPhones.
Well, I still claim to know little or nothing about DNSSEC, but I managed to sign one of my zones, tengigabitethernet.com., and add it to the DLV registry, this evening.
Visualization is here.
Once I write some scripts to automate the rotating of my ZSKs, I'll sign the rest of my zones.
Recently, I described my experience of transitioning from a line of Nokia phones to the Nexus One. One thing that I tried initially, and failed at, was to create some custom wallpaper. I think I've figured it out, although through a hacky sort of solution.
The Nexus One has a display size of 800x480 (HxW) pixels. This resolution is fairly high for a device of its size, which is good, considering its strange two subpixel PenTile display. The wallpaper on Android is usually quite a bit larger than the single display, since the wallpaper scrolls left & right as the user scrolls between different screens. According to specifications, the wallpaper for the N1 should be 960x800.
I created some wallpaper with 960x800 dimensions, and tried it out. However, Android kept prompting me to select a subset of the image and display that as wallpaper (ie, cropping). I tried this out, and got a slightly resampled image, which looked terrible. Wanting wallpaper that wasn't resized on the phone, I looked around, and learned that it's necessary to create an image with larger dimensions than either the screen or wallpaper specifications indicate.
After trying a few things, it turns out that an image of 1600x1200 with actual centered 960x800 content is the sweet spot. Let me illustrate:
I took the beautiful Funchal Bay scene by Ruben Freitas and resize & cropped it to 960x800. Then I expanded the canvas to 1600x1200, while keeping the original image intact. When uploaded to the phone, the crop box by default encompassed the original 960x800 image exactly.
I'm sure there's a better way of doing this, but this works for me!
Also, happy Independence Day!
This is starting to annoy me.
There are a few intersections in the Charlotte area that often present confusion to some drivers. I'll go over two examples that I encounter every single weekday (I am the lime vehicles), and then recount a situation I encountered today.
Consider Ballantyne Commons intersecting with John J. Delaney / Durant Blvd:
The lime and cyan vehicles both start out having green lights. The NC driver's manual (grab it here) indicates that the lime vehicle should turn into the left lane, and the cyan vehicle should stay in the right lane close to the right edge of the road (page 51). This is the way I drive, and this is the way most people drive.
Unfortunately, sometimes you'll see the lime vehicle pause in the middle of the intersection, waiting for the stream of cyan vehicles to stop before turning left. This is annoying, jams up the intersection, and causes pain and anguish for drivers who know the light is typically very short. When I'm the lime vehicle behind another, erm, lime vehicle stopping in the middle of the intersection, I will blow the horn at them.
Sometimes, the cyan vehicles will turn right into the left lane of Ballantyne Commons Pky, causing a potential collision with the lime vehicles. If I'm the lime vehicle, I will blow the horn at these vehicles, too.
Note that if Ballantyne Commons Pky only had one lane in each direction, the cyan traffic would have the right of way, and the lime traffic would have no choice but to hang out in the intersection.
I've only had to do this a few times in this intersection.
Onto another intersection with identical properties, the I-277 offramp intersecting with E Stonewall St:
Here we have the same thing. Both the lime and cyan traffic both have the green light. Lime traffic should turn into the left lane of E Stonewall St and the cyan traffic should turn into the right lane. In this intersection, the cyan traffic does actually have two options, the yellow line is a right turn only lane. Both the right turn only lane and right lane are acceptable paths. This is described in the same section of the driver's manual.
One thing that makes this intersection different than the prior one is the traffic volume. There is hardly any lime traffic volume (usually, I am the only one in the left-turn lane) but there is a steady stream of cyan traffic (this is around 17:25 on a weekday). The light is still pretty short, though. Again, I'll blow my horn at lime traffic in front of me that doesn't move, and cyan traffic that veers into the left lane of E Stonewall St.
Ok, having set the stage, here's what I encountered today (2nd intersection). Heading to MCAC, I found myself behind another vehicle turning left on E Stonewall St, and I noticed that this guy was waiting for the (cyan) traffic to stop before he turned left. He wasn't moving at all, so I gave him a beep or two. He didn't move at all, and, well, I got around him (ok, probably not the best thing to do, but not relevant to the discussion at hand!).
Turns out he was headed to the same destination, and confronted me once inside the aquatic center if I was the "guy in the silver Acura that shot past him." Yep, that was me. He asked why I beeped him and took such action. After realizing he wasn't going to beat me up (ok, he was driving a big white Ford pick-up truck - I suppose I wouldn't have felt that way if he had been driving a medium-sized sedan, but whatever), I told him I've had some bad experiences with folks sitting in the middle of the intersection and not budging, alluding to the fact that the light didn't stay green forever. He then said he didn't turn left because he was worried the oncoming (cyan) traffic turning left was going to go into the left lane, which none did as he was waiting in the intersection. Although it came out rather strangely, I conveyed to him that it was certainly legal to turn left into the left lane, and that the oncoming traffic should stick to the right lane. He then asked me if there was a sign somewhere in the intersection that stated this! I don't recall what I said to that, but ended up apologizing (why did I do that? I am hating myself for doing it!) and we went our separate ways. He did mention this was the first time he drove through the particular intersection, so I suppose it's not bad to be cautious, but still.
So, hopefully this guy won't make the same mistake twice. Either that, or he will just avoid the intersection…
On that note, sometimes I feel the need to carry around the driver's manual in my glove box. You never know when it'll come in handy!
Displaying page 15 of 121 of 965 results
     |
This HTML for this page was generated in 0.006 seconds. |