|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
I was poking around on my N1 today, and stumbled across an application, aptly named Antennas, that lists and plots active cellular sites in the area. Surprisingly enough, here's what AT&T looks like from my condominium in Ballantyne:
I always thought I was connected to a cellular site hosted on some power lines by the Ballantyne Hotel, but I guess that's not AT&T's. I'm apparently connected to one in the woods behind my development:
I wonder if it's nailed to a tree, or something. Well, I guess that's not allowed.
I've finally done it. I've washed my hands of Nokia for good. I recently picked up a Nexus One and only looked back once or twice. I figured this deserves a blog entry…
I've owned several Nokia E-series Symbian-based phones since March of 2007. I've used all of them on AT&T's network in the United States:
(yes, I would sell each previous phone on eBay for roughly half the price I paid, except for the E72.. read on to find out why)
The E61 and E61i were good phones. Maybe they were a little slow (speaking both about CPU and the data service delivered by the EDGE technology) in comparison with other things, but they were stable. There were no screen transitions, no frills, and the eMail client worked well. The QWERTY keyboard was large, and the screen was easy on the eyes, not to mention being easily viewable in direct sunlight.
The problems started with the E71, even though the hardware was a big step up from the E61[i]. UMTS (3G technology), a faster CPU, and nice 3.2 megapixel camera were the main features of the E71. Unfortunately, Nokia decided it was going to try to soup up Symbian with some extra silly features, including a camera application that was bloated beyond belief and "modes" that were supposed to help switch between personal and work mode. It also was a smaller phone, which didn't really bother me, but made me miss the size of the E61[i]. The phone also had some major bugs, and crashed quite a bit.
I don't know why I upgraded to the E72. Maybe I just wanted the faster HSDPA (10.2 Mbps vs 3.6 in the prior models, even though AT&T only offered ~7 Mbps in certain areas) and the upgraded 5.0 megapixel camera. Well, this phone was a disaster. I'm going to have to resort to a list, here:
For the eMail client, I don't know what Nokia was thinking. It doesn't support IMAP IDLE (although Nokia says that the phone supports push eMail), and reconnecting to check mail takes almost 2-3 minutes, with the eMail application crashing half the time. It's so bloated, and even the simplest of tasks appears to lock up the phone. It looks like the mail client needs tons of optimization, and was designed for a phone with a much bigger screen resolution. For the E72, it was terrible. I actually stopped using the phone to read eMail, as a result. Oh, and one other thing - if the eMail client is allowed to pull all messages from a folder (which is the default for manually-subscribed IMAP folders), it'll consume all available memory, storage, and require a HARD reset to get things back to normal (yup, reboots and deleting of mailbox definitions doesn't fix this).
As a result, the phone was a pain to use. However, it does have some good points:
Ok, maybe not too many.
I mulled over the alternatives (Android handsets, iPhone, and Nokia N900) and determined I wanted to go Android.
I knew the major struggle with this phone was going to be getting over the lack of a QWERTY keyboard. It seems that everything is moving to touchscreens these days, so I figured I should get used to it.
The phone itself is easy to use. It took me a little bit to get over the QWERTY keyboard, which is more difficult to use than the one in the iPhoneOS (erm, iOS). The voice recognition is nice, though, and fairly accurate (you can speak instead of typing, most of the time). The eMail client works (yay!), the browser is quick, and the camera (5.0 megapixel) provides decent quality. The battery life could be better.
The N1 runs Android. Android is a weird operating system. It's based on the Linux kernel, but the userland isn't what one would normally expect from a typical Linux distribution (directory hierarchy, etc.). All applications seem to stay in memory to aid in multi-tasking, and therefore the amount of free memory is quite low under normal circumstances. Android Market is a centralized shop for applications for rooted and non-rooted phones, which I found strange.
The phone runs Android 2.1_update1, and can be unofficially upgraded to 2.2. The T-Mobile N1 has an official upgrade, but the AT&T version does not, at time of this writing.
Instead of unofficially hacking 2.2 onto the N1, I unlocked the bootloaded and loaded CyanogenMod, which is a modified Android 2.1_update1 with extra features like FLAC support, OpenVPN binaries, extra Unix utilities, and is pre-rooted.
I've got OpenVPN running just fine, and am also using Sipdroid VoIP to connect to my Asterisk system. Well, Sipdroid works well over OpenVPN over Wi-Fi, but barely works over AT&T, due to the jitter on HSDPA. I'm sure if I were near a tower at 03:00, it would work fine, too. I blame all the iPhone users during the day..
I settled on QuickSSHd to allow SSH access to the phone, which lets me securely copy stuff off or onto the phone wherever I am. Much easier than plugging in USB and playing with cables. Since CyanogenMod comes with rsync, it makes it even easier.
Tethering via Wi-Fi, Bluetooth, and USB all work great. Tethering via Wi-Fi does drain the battery very quickly (much more quickly than using JokiuSpot on the Nokia E-series phones, strangely enough).
The phone does support IPv6, and it works great over Wi-Fi. I haven't tried any IPv6 tunneling on the phone, yet.
Now, onto the gripes.
There is a huge bug in Android 2.1_update1 that causes the Wi-Fi radio to shut off whenever the screen turns off. There's a "Wi-Fi Sleep Policy" option in the Wi-Fi advanced settings that supposedly allows one to control when Wi-Fi sleeps (never, only with cable connected, when screen turns off) but none of the options make any difference. There appears to be no remedy to this other than just running an application that will not shut off the screen (Wi-Fi Analyzer has an option for this, among others). Obviously this is a complete waste of power, and presents a real problem for N1 owners.
Supposedly Android 2.2 fixes this issue, and CyanogenMod 6.x will be based on 2.2 whenever the source code is released. I'll be waiting for this day!
Other than that, I've only had one other problem with the phone, which happened yesterday. I've been using Open GPS Tracker to plot routes & speed I take through Charlotte. Unfortunately, when I was driving, the phone crashed and went into an endless reboot cycle. Reading online made me think I might have to do a hard reset, but thankfully booting into safe mode then rebooting again fixed it. I was thinking Open GPS Tracker was causing the problem on bootup, but apparently not.
Normally, I would have sold my old Nokia phone on eBay (it's going around $250 at the time of writing) by now, but unfortunately it seems the security code has been changed. I don't remember changing it, and neither the default code (12345) or my old security codes work. Apparently, the only way to reset this is to send the phone back to Nokia so they can hack it, or something. I found this page which detailed a procedure to add a file to the SD card, and boot the phone. Unfortunately, it didn't work.
So, I'm left with a Nokia E72 in great condition, sitting on my shelf. I don't want to sell a phone with a locked security code.. or do I?
Uh, what's going on here?
I'm going to be surprised if I receive this tomorrow.
Yep, I took a trip with my family to London and Paris. It was fun!
We took a flight from Newark to Heathrow via British Airways on May 15th (local date), stayed in London until May 20th, then took the Eurostar to Paris. Air France returned us to the USA on May 23rd.
Among other things, bad weather, British Airways union strikes, and volcanic ash were all avoided.
In total, I took over 800 photos, 55 video clips, and 2 timelapses. My cellphone captured over 100 photos, too. I've dispersed links to the photo galleries throughout this blog entry, but if you are impatient and don't care to continue reading, you may use the following links:
Note: most of these photos haven't been labeled. I'm working on it, but it will take time.
I'll cover short summaries of both cities, transportation to and from, some conclusions, and some other thoughts relevant to the trip.
We arrived in London Heathrow Airport on Sunday, May 16th and briefly hooked up with our tour group for the bus ride to the hotel. Before we left I acquired some GBP at a fairly horrible exchange rate.
We stayed at the Thistle Marble Arch hotel for our stay in London, which is near the Marble Arch at Hyde Park. Although the hotel was a little bit dated, it provided for a pleasant stay.
For the remainder of the first day, we wandered around Hyde Park and what apparently was the shopping district of London. We visited some department stores (Harrods) then had dinner, and afterwards got stuck in the rain and took a taxi back to the hotel. I'm pretty sure I tipped the taxi driver a bit too much, but I don't think he minded. He was probably thinking "stupid American tourists, ha ha!" or something.
The next day we obtained some travel cards (which we did every subsequent day, too) for the mass transit system (the tube and the bus system). The London Underground was fairly easy to navigate, and very clean compared to other subway systems I've used in the past.
The first attraction we encountered was a full contingent of Grenadier Guards practicing at Pall Mall for the Queen's birthday (it's in April, but officially celebrated in June). We were really too far away to get any good shots, though.
We then took a tour of the National Gallery and had lunch at the café. It was the first time I noticed a sign warning of pickpockets. Little did I know this would be a theme during the course of the week.
After departing the National Gallery, we visited the London Eye, which is essentially just a big Ferris wheel overlooking the River Thames.
(more London Eye photos)
Before riding it, we watched a small movie while standing up and wearing 3D glasses. Entitled the "4D experience" (or something like that), it was fairly silly show, and ended up just being a waste of time. The London Eye itself was pretty neat, and provided a nice view of Big Ben and the Houses of Parliament. Unfortunately, it was very sunny, and most of the photos I took contained a bit of glare.
After the London Eye, we wandered around Big Ben, Parliament, and Westminster Abbey. Across from Parliament was a square completely covered with signs and tents protesting various things. Nobody was really walking near it, probably for fear of being screamed at or something. It was weird. We finished off the day eating at a nice Italian restaurant, Signor Sassi.
The next day (Tuesday, now) we started off by stumbling across an Apple Store, not initially realizing that this is the only place in London with free Internet access. We hit St. Margaret then took an extensive tour of Westminister Abbey. They didn't allow photos. We ate lunch in the crypt of St. Martin-in-the-Fields, which was weird. What was also weird is the cashier taking 5-6 minutes to authorize my credit card. Maybe the Internet or phone lines were dead.
We then walked by St Paul's Cathedral and took the Millennium Bridge across the Thames to visit Shakespeare's Globe Theatre (a recreation, of course). We caught the first act of Henry VIII before moving onto the Tower Bridge.
We took the tour of the Tower Bridge, and then ate dinner at Côte Restaurant. The bridge was fairly impressive. I don't know what I was thinking, but for some reason I was under the impression it wasn't used anymore. Silly, I know!
(more St Paul's Cathedral photos)
The next day we made our way to St Paul's Cathedral and took the tour. This was probably one of the highlights of the trip. The cathedral itself was very impressive (no photos inside.. boo!) and also served as a burial place for several people, including Christopher Wren (he designed the cathedral). The best part of the tour was the visit to the galleries. The galleries were walking areas high up in the cathedral, and required climbing quite a few steps in order to reach them. The whispering gallery is 257 (30m) steps up, and provided a breathtaking view of the inside of the cathedral. Everyone was supposed to be quiet (whisper) but this little kid kept screaming "papa" loudly - it echoed all over the place. The stone gallery was 376 (53m) steps up, and provided a nice view of London. The last gallery required 152 more steps through small passageways and provided an 85 meter high view of London. It was great!
We ate lunch at the crypt in St Paul's. It was a nice sit-down restaurant. I don't know why we kept eating in crypts. The rest of the day was spent visiting Buckingham Palace, watching more of the Grenadier Guards, and eating dinner at Pizza on The Park (fairly fancy pizza dining, not what I was expecting!) at Knightsbridge.
Thursday was our travel day to Paris. We took the Eurostar, which took a little over two hours. The ride in the Chunnel only lasted around 20 minutes, though.
After arriving in Paris on the Eurostar (and eating lunch on the way), we spent the rest of Thursday with the tour group. It consisted of driving around Paris, listening to a French tour guide making silly comments about The Thinker statue, and stopping briefly for dinner. We chose Café Panis, where I had steak with French fries (they tasted like Burger King fries).
In the evening we took a ride on the Seine, which consisted of some interesting sights, a nice sunset, and one or two bare-chested teenage girls who flashed us from the Left Bank. Yeah, apparently they like to have fun with tourists.
Around 22:00 we watched the Eiffel Tower sparkle for a few minutes. Apparenly it does this on the hour in the evenings until early morning. It's too bad the tour bus was stuck in a jam during the first sparkle session, so we couldn't get out to take proper photos.
We stayed at the Pullman Bercy hotel, which was quite new, and provided (gasp!) complimentary Internet access.
On Friday we took the Paris Métro from the Cour Saint-Émilion station to the Musée du Louvre.
As a side note, we obtained a bunch of metro passes (single ride only) that were supposedly good on both the Paris Métro and the RER, to get around town, just like we did in London. Unfortunately, the passes didn't seem to work consistently, which left us wondering if they were only supposed to work in certain lines. After constantly having to replace the tickets (or have random people let us out of the subway, at times), we concluded that the tickets were either demagnetizing very quickly or the ticket printer at the Cour Saint-Émilion station was faulty. It proved rather annoying, combined with the "unpolished" subway system and RER being non-functional at times.
(more Lourve photos)
The Lourve was nice. Well, it was amazing. I took a short timelapse of the lobby:
Unlike all the other museums we visited during the week, the Lourve was the only one that allowed photography (non-flash, but that didn't stop anyone). I took quite a few photos. We saw the Mona Lisa, of course, which was fairly small. There was a huge crowd in the room, though. Some of the other highlights from the Lourve were the following (sorry for the excessive Wikipedia links, but really, it provides the best information):
We ate lunch at the museum.
The next attraction was the Eiffel Tower. Boy, this was a pain in the butt. Normally two pillars provided lifts to the top, but that day only the north lift was working, so the line was extensive. We did make it up to the third level (top). Very nice view, and there was even Wi-Fi provided (not free, of course) at the top. The whole thing took a total of three hours. Feet were very sore. While waiting in line on the ground, we witnessed one of the souvenir guys getting hauled off by the French police, supposedly due to pickpocketing. Apparently it's a fairly active sport.
Dinner that night was at the hotel, which was very nice.
Saturday started out with a trip to the Musée d'Orsay, where we couldn't take any photos, but saw lots of Monet and van Gogh. We ate lunch at the museum restaurant, which was fairly ornate (lots of gold trim).
(more Arc de Tripmphe photos)
We then headed to the Arc de Triomphe, and spent way too long trying to figure out how to get across the free-for-all traffic to reach the monument itself. Turns out there's two underground passages. I did see a couple people run through traffic and almost cause an incident.
On the way to Café de la Paix (warning, the website resizes your browser) for dinner, we walked through Champs-Élysées, but didn't buy anything. I snagged some free Wi-Fi near Fouquet's, though.
On Sunday, we took a bus trip to the Charles De Gaulle Airport, and flew home via Air France. I snagged some Ubuntu Cola in the terminal, before boarding.
Overall, the trip was fun. I think I liked London better than Paris, though.
London is a very diverse city (population-wise), maybe even more than New York City. It's also quite clean and easy to navigate. The Underground was a cinch, and I didn't see any graffiti or vandalism anywhere.
Paris, although home to beautiful museums and monuments, reminded me of NYC. It was quite dirty compared to London, and seemed to be a large amount of graffiti and vandalism all over the city.
The transportation wasn't bad. The BA flight to London was uneventful, but my seat was uncomfortable. I didn't get any sleep. The Air France flight was the same - butt was uncomfortable the whole time. I actually took a 10-15 minute nap on the Eurostar, though! Very comfortable.
Both cities seemed to suffer from pickpockets. There were signs posted in various locations advising tourists that pickpockets operate in the area.
One thing about the populations of London and Paris that took me a day or so to realize: there's no obesity. I only saw one obese person (who wasn't on the tour) during the course of the whole trip. Is it portion size? I think it might be - portions in the USA are out of control, it's something we need to work on.
Maybe it's related to the above, but I think that on average the women in London are far more attractive than women in the USA. Maybe it was because we were constantly surrounded by tourists, I'm not sure. Paris.. sorry, London's got you beat in this category, too.
There were lots and lots of class trips in London. I saw at least 4-5 groups of schoolchildren every day. Seeing class trips at the museums and the cathedrals was one thing, but we saw a couple groups just wandering the streets of London. Seemed odd.
Smoking. There were lots of smokers in both cities. Why? Have Europeans not figured out that smoking kills? Not only that but it's a turn-off. A shame.
Although we could have stuck with our tour group for the whole trip, we decided to spend a maximum of half a day with them, and take on both cities by ourselves. In retrospect, there's no doubt this was the right choice. Learning the mass transit and actually walking places provided much more insight than sitting in an air-conditioned tour bus jammed up in traffic. Also, we never felt rushed when spending time at the various museums and attractions. It would have been nice to learn some "tips" along the way, but I don't think we missed too much in that regard.
Wi-Fi. There were hardly any open Wi-Fi hotspots in either city. I'm talking about free access, not Boingo or any of the other providers that require payment. In the UK, apparently there's a law indirectly prohibiting this, which explains why I didn't encounter any free Internet acces in London (except the Apple store!). In Paris, I only came across two open networks, the hotel and Fouquet's.
We were wondering why every restaurant served us bottled water. Apparently tap water in London has a higher concentration of microbes than water in the USA. I found this out after the fact, I guess this might have been nice to learn from the tour guide, if we had taken the guided tours.
My Nokia E72 (E72-2) somehow worked on Orange UK and Orange France's UMTS networks just fine. However, AT&T's international roaming data rate is $0.0195/KB. I figured this out while still under 3MiB, otherwise it would have been disastrous. I didn't really use the phone on the trip, for this reason. It would have been nice to use Google Maps while wandering around the cities, but oh well. AT&T offers a couple packaged international roaming data plans, but none of them seemed to be worth it, and there isn't an easy way on my phone (or on AT&T's site, since it updates so slowly!) to keep track of the data usage, to prevent going over.
I guess one bad thing happened during the trip. On the second day of the trip, Ballantyne had a five hour power outage. All the computers in my condo died and remained off until I returned. Power bill was low, though!
As I mentioned recently, I'm now running an Intel Core i7-980X processor (6x physical cores, each capable of executing 2x threads via Intel HT, abstracted by the OS as 12x CPUs) in my workstation. It's running great, but I've been lacking the ability to view CPU temperature readings from the operating system (Debian GNU/Linux x86_64 with a slightly modified kernel 2.6.32).
None of the modules for lm-sensors picked up anything on my DX58SO board that would report temperature. The ACPI thermal zone module didn't pick up a thermal zone, and the coretemp module in the Linux kernel whined that it didn't support the CPU model:
[462200.646777] coretemp: Unknown CPU model 2c [462200.646780] coretemp: Unknown CPU model 2c [462200.646782] coretemp: Unknown CPU model 2c [462200.646783] coretemp: Unknown CPU model 2c [462200.646785] coretemp: Unknown CPU model 2c [462200.646786] coretemp: Unknown CPU model 2c [462200.646787] coretemp: Unknown CPU model 2c [462200.646789] coretemp: Unknown CPU model 2c [462200.646790] coretemp: Unknown CPU model 2c [462200.646792] coretemp: Unknown CPU model 2c [462200.646793] coretemp: Unknown CPU model 2c [462200.646795] coretemp: Unknown CPU model 2c
Yes, it apparently went through every virtual CPU (or should we call it a thread, I don't even know anymore!).
I took a guess that the interface didn't change too much in the Gulftown vs. the original Bloomfield line of processors, so I took a peek at coretemp.c, and added in the new model code:
--- coretemp-orig.c 2010-05-09 19:43:06.000000000 -0400
+++ coretemp.c 2010-05-09 19:43:12.000000000 -0400
@@ -455,12 +455,12 @@
/* check if family 6, models 0xe (Pentium M DC),
0xf (Core 2 DC 65nm), 0x16 (Core 2 SC 65nm),
0x17 (Penryn 45nm), 0x1a (Nehalem), 0x1c (Atom),
- 0x1e (Lynnfield) */
+ 0x1e (Lynnfield), 0x2c (Gulftown) */
if ((c->cpuid_level < 0) || (c->x86 != 0x6) ||
!((c->x86_model == 0xe) || (c->x86_model == 0xf) ||
(c->x86_model == 0x16) || (c->x86_model == 0x17) ||
(c->x86_model == 0x1a) || (c->x86_model == 0x1c) ||
- (c->x86_model == 0x1e))) {
+ (c->x86_model == 0x1e) || (c->x86_model == 0x2c))) {
/* supported CPU not found, but report the unknown
family 6 CPU */
I did a make-kpkg kernel-image to rebuild the kernel image the Debian way, and installed the new kernel (didn't bother rebooting, since only the module changed). It seemed to load fine. I got some warnings in the kernel log buffer after the module was loaded:
[463606.992361] coretemp coretemp.0: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992417] coretemp coretemp.1: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992449] coretemp coretemp.2: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992483] coretemp coretemp.3: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992516] coretemp coretemp.4: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992554] coretemp coretemp.5: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992592] coretemp coretemp.6: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992629] coretemp coretemp.7: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992665] coretemp coretemp.8: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992698] coretemp coretemp.9: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992734] coretemp coretemp.10: Unable to access MSR 0xEE, for Tjmax, left at default [463606.992768] coretemp coretemp.11: Unable to access MSR 0xEE, for Tjmax, left at default
After refining my Google search terms a few times to avoid clothing stores, apparently Tjmax is an abbreviation for Thermal Junction Maximum - essentially the maximum temperature of the processor that will trigger a shutdown. I figured that wouldn't affect current temperature readings, and looked at some of the values:
(destiny:19:49)% sensors coretemp-isa-0000 Adapter: ISA adapter Core 0: +78.0°C (high = +80.0°C, crit = +100.0°C) coretemp-isa-0001 Adapter: ISA adapter Core 1: +73.0°C (high = +80.0°C, crit = +100.0°C) [...] coretemp-isa-000a Adapter: ISA adapter Core 10: +70.0°C (high = +80.0°C, crit = +100.0°C) coretemp-isa-000b Adapter: ISA adapter Core 11: +70.0°C (high = +80.0°C, crit = +100.0°C)
Yikes! 12 values? Apparently coretemp iterates through every CPU (as we saw in the original module loading error messages), regardless if it's a virtual CPU or not. So, we apparently have 12 temperature values. They all seem to vary by a degree or so, too. And yes, I was doing some H.264 encoding at the time I took the snapshot above, normally temperature is around 32°C.
There's apparently a small discussion about this oddity, and how to correctly report CPU core temperatures on multicore processors with HT. Right now, I'm still scratching my head about the fact that the virtual CPUs are all reporting slightly different temperature values. I would have expected odd numbered CPUs to report NULL, or something. Or maybe even just the same value as the previous CPU.
Regardless, I'm now graphing all the threads / virtual CPUs!
It's never good to see this in your inbox while at work:
5795 May 03 root (1.0K) starfire Power Failure !!! 5796 May 03 root (1.1K) atlantis Power Failure !!! 5797 May 03 root (1.1K) destiny Power Failure !!! 5798 May 03 root (1.1K) atlantis Power has returned 5799 May 03 root (1.1K) destiny Power has returned 5800 May 03 root (1.0K) starfire Power has returned 5801 May 03 root (1.1K) destiny Power Failure !!! 5802 May 03 root (1.1K) atlantis Power Failure !!! 5803 May 03 root (1.0K) starfire Power Failure !!!
Yep, there was a huge power failure in Ballantyne this morning. I think it lasted for about an hour, but I'm not completely sure. Lights were out and cops were directing traffic. Power came back about a minute before I arrived home. Lots of uptime lost!
The only systems that came back online automatically were my SGI O2, Soekris box, and Juniper firewalls. The Eee PC and IBM T42 were still online.
Over the past couple of years quite a few transition mechanisms and models have been created to ease the deployment of IPv6 into ISPs and enterprises. Some of the recent ones have very similar names, and can be easily confused with each other. I'm going to attempt to summarize them all here as concisely as possible in my own words, and possibly put them in some sort of logical order (or not).
(Update: Added 6rd and DS-Lite!)
Request for Comments: 3056
Summary: 6to4 is probably the oldest and original IPv6 transition mechanisms. It essentially allows any host with only IPv4 connectivity to communicate with IPv6 hosts using 6in4 (IPv4 protocol number 41) tunnels through one or many public 6to4 relays operated on the Internet. Each IPv4 host using 6to4 assigns itself a prefix out of 2002::/16 in the form of 2002:<IPv4 address in hex>::/48. It then forwards all (well, not 2002::/16) IPv6 traffic toward the nearest anycasted 6to4 relay (192.88.99.1).
Pros: Everything supports it, by now. It's fairly simple to setup.
Cons: Due to Internet routing issues, it's not guaranteed to work. Anycasting with BGP does not guarantee low latency. In fact, latency to the closest (AS_PATH speaking) 6to4 relay is often 100s of ms away! Whenever the host's IPv4 address changes, their whole IPv6 /48 based on that address must change, too. Also, 6to4 doesn't work through IPv4 NAT too well.
Request for Comments: 4213
Summary: 6in4 is a generic term that's used to describe the encapsulation of IPv6 packets in IPv4 packets with a protocol number of 41. In a sense, it's a manual version of 6to4, but much more flexible. In the case of two networks separated by the Internet, one dual-stack and one IPv4-only, one would build a 6in4 tunnel between the sites, and route IPv6 prefixes to the IPv4-only site to provide IPv6 connectivity. This is the main method of "do it yourself" IPv6 tunnels that are offered by several organizations (often called "tunnel brokers"). Hurricane Electric and SixXS (pronounced six-ess, like success) are two of the most popular organizations that offer these type of tunnel services with the main goal of providing end-users access to the IPv6 Internet.
Pros: It's quick and easy. Most public tunnel brokers will provide a /48 prefix of PA space to end-users.
Cons: By their definition, 6in4 tunnels are static, so the change of either IPv4 endpoints requires a re-build of the tunnel, or at the minimum a reconfiguration (although wrapping the 6in4 tunnel with OpenVPN eliminates this issue). MTU issues can exist, if both sides do not coordinate the setup correctly, or if the MTU along the path decreases in a failover scenario.
Request for Comments: 5214
Summary: ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) allows two dual-stack nodes to communicate via IPv6 over an IPv4-only network. ISATAP, geared toward enterprises, was developed by Microsoft, and views the IPv4 network as one big flat link layer for IPv6. ISATAP creates link-local addresses to be used on the virtual "link" by appending 0x5efe plus the host's IPv4 address. Global addresses can be assigned on the ISATAP link via autoconfiguration or DHCPv6, as well. Clients discover the ISATAP routers by performing an IPv4 DNS query for isatap.<domain> upon connection to the network. The IPv4 transport uses protocol number 41, just like 6to4 and 6in4.
Pros: It's fairly automatic and doesn't require any configuration on the client.
Cons: Relies on IPv4 DNS, which some folks consider a circular dependency. MTU issues could also exist.
Request for Comments: 4380
Summary: Teredo is a tunneling protocol that shares a similar goal with 6to4, yet uses UDP (port 3544) instead of 6in4 to improve NAT traversal. A Teredo client will contact a server and obtain a single address consisting of a combination of the client IPv4 address, source port number, Teredo server IPv4 address, and some flags. The server handles the first packet, and then directs the traffic through a Teredo relay that's closest (AS_PATH speaking) to the IPv6 host. Relays advertise 2001:0::/32 into BGP, and this is the prefix that Teredo addresses are built from.
Pros: Simple to setup (Windows Vista/7 enables it by default if no RAs are received). It works great through all sorts of NATs. Easy to troubleshoot since the same relay is used for communication in both directions.
Cons: Only one address is allocated per Teredo client. It's so easy to setup and works so well that it may inadvertently expose hosts on a secured IPv4 network to the IPv6 Internet.
IETF Internet-Draft: draft-shirasaki-nat444-isp-shared-addr-02
Summary: NAT444 is a model that ISPs can use to deploy IPv6 to both commercial and residential customers without removing IPv4 access or replacing CPE equipment with specialized hardware. CPE (customer premise equipment) hardware can be a standard Linksys router or something with more functionality and performance. Although NAT444 can be deployed commercially, it appears to be designed around residential customers (MSO/DSL). The customer's network in NAT444 is dual-stack, with the IPv6 prefix(es) being globally-unique and assigned by the MSO, and the IPv4 addresses chosen by the customer (or more likely, the default configuration of the CPE). The IPv6 traffic is routed natively by the CPE, via the provider's backbone toward Internet peers and on to the destination. However, the IPv4 traffic encounters NAT (or more accurately: NAPT) at both the CPE and what is generically termed an LSN (large scale NAT) or CGN (carrier-grade NAT) device at the provider's edge. IPv4 traffic is translated a total of two times before it reaches the Internet. The two layers of NAT are required because NAT444 may be deployed on a new ISP at a point in the evolution of the Internet where virtually all the IPv4 space has been exhausted, and there may be no way for the provider to allocate addresses beyond the bare minimum that are required for the LSN/CGN devices. The IETF draft mentions class-E (240/4) and RFC1918 addresses that are candicates that can be used on the ISP's backbone network.
Pros: Assuming more CPEs start featuring IPv6 functionality, NAT444 is the only model that doesn't require the replacement of the CPE with some specialized hardware (and most likely centrally-managed) from the ISP. No DNS or address family translation is needed, which avoids most of the headaches and complexity common with many other migration designs.
Cons: Where do I start? Performing two sets of NAPT ("double-natting") causes large problems with numerous applications ranging from online gaming to VoIP. Unsolicited inbound connectivity may be impossible unless the ISP decides to offer some sort of customer portal service that can be used to reserve a set of ports on one or more addresses in the LSN/CGN pool for the customer. Even with this, the customer will have to configure the port forwarding on the CPE device, too. Auditing is also difficult with NAT444 because hundreds or even thousand customers could be sharing one IPv4 address. This also opens the door for botnets and spam to potentially get one or more of the LSN/CGN pool addresses blacklisted by any number of centralized RBLs (using the term loosely) on the Internet, effectively denying service to all the other customers who may be translated to these addresses.
IETF Internet-Draft: draft-mrw-behave-nat66-02
Summary: NAT66 is a method of providing flexibility for the migration of IPv6 networks that do not qualify for PI (provider independent, or in other words: portable) space between ISPs. A small network is typically provided a block of PA (provider assigned, or in other words: not portable) space when purchasing service from an ISP. However, if the network needs to change ISPs, all hosts and network devices must be renumbered, a time-consuming and hellish process. NAT66 defines a unique translation method that performs NAT between hosts on an internal network to a prefix provided by an ISP or other upstream provider. The NAT66 device does not track sessions and does not perform port translation. Additionally, an "algorithmic" approach to address selection during NAT allows for the assignment of translated addresses that cause the original and translated packets to share the same checksum. Although any prefix can be used on the internal network, it is recommended to use ULA addresses to prevent conflicts. DNS configuration must be altered whenever the PA space changes.
Pros: Somewhat easy to immplement. No state needs to be maintained on the NAT66 device.
Cons: The PA prefix must be 48 bits or less, otherwise the original and translated packets may not share the same checksum, potentially breaking some IP security imeplementations. Just like with any NAT, applications that encode the host's source address in the payload of the packets (stream) will require additional configuration or ALGs (application-level gateways) that can aid the translation of the payload on-the-fly.
IETF Internet-Draft: draft-ietf-behave-v6v4-xlate-stateful-11
Summary: Very similar to NAT-PT (RFC 2766), which has since been deprecated, NAT64 provides a mechanism for IPv6-only hosts to communicate with IPv4-only hosts through a device that implements NAT64 assisted by a DNS server that implements DNS64. NAT64 is stateful, meaning that the NAT64 device keeps track of all connections, since the addresses on the IPv4 side of the NAT64 device are obviously in short supply, and must be overloaded, using port translation. DNS64 allows IPv6-only hosts to be provided synthesized AAAA RRs that actually point to IPv6 addresses with embedded IPv4 addresses. These addresses ultimately are routed to the NAT64 device that map connections to the IPv4 host in question. New connections initiated from IPv4-only clients back to IPv6-only clients are only allowed with the definition of static mappings and optionally custom DNS records (DNS64 does not help with this).
Pros: Provides a [better] replacement for NAT-PT and NAPT-PT.
Cons: It's complicated, and only works with TCP, UDP, and ICMP. The combination of having to synthesize AAAA RRs and maintain complex session state seems to make this setup quite fragile. Communication is also only one-way by default.
Request for Comments: 5569
Summary: 6rd stands for IPv6 Rapid Deployment. It's very similar to 6to4, and even uses the standard IP protocol 41 method to encapsulate the IPv6 packets into IPv4. However, it's different because it's only used within an ISP, which doesn't need to have a dual-stack backbone. An ISP first sets up a 6rd relay at their edge, and connects it to the IPv6 Internet. It then sets aside a prefix that will be used for 6rd, and the ISP's customers use this prefix + IPv4 address to build their own prefix that can be used for SLAAC internally. The ISP anycasts their 6rd relays and preconfigures the customer's CPEs (which ends up being just a modified 6to4 implementation) to connect to tunnel IPv6 traffic to this address. Traffic destined to this prefix (return traffic) from the Internet gets routed to the customers via the 6rd relays.
Pros: Easy to implement. No need to dual-stack the whole ISP's backbone. Does not imply the need for LSN/CGN.
Cons: The 6rd address space can't be a prefix longer than 32 bits. This requires the ISP to get a prefix shorter than a /32 from its RIR. Modification of CPEs is necessary.
IETF Internet-Draft: draft-ietf-softwire-dual-stack-lite-04
Summary: Dual-Stack Lite (or shortened to DS-Lite, and sometimes slightly incorrectly referred to as NAT464) is very similar to NAT444, with the exception that IPv4 NAT is only performed once, by the LSN/CGN at the ISP's edge. Just like NAT444, DS-Lite will most likely gain popularity once all free IPv4 blocks have been exhausted. Using a custom CPE running a piece of the AFTR software, IPv4 connections from a customer's network are tunnelled over the ISP's IPv6 backbone to the LSN/CGN, where connections reach the IPv4 Internet. So, essentially, DS-Lite is like NAT444, but the IPv4 connections across the ISP's backbone are tunnelled inside IPv6. The LSN/CGN devices also add the CPE's IPv6 address to the NAT translation table for IPv4 connections, since it's likely that many residences will overlap with each other's RFC1918 space.
Pros: Eliminates the issues associated with performing NAT twice. Requires very little IPv4 addresses.
Cons: CPEs must be replaced. This is a large undertaking. MTU issues may arise due to the IPv4 tunnelling.
I'm finally sitting down to blog this, even though I'm being attacked by allergies, and losing the battle.
I recently upgraded my main workstation, destiny from an Intel Core 2 CPU to an Intel Core i7 CPU. Here are the specifications of the new (finished) upgrade:
The only things remaining from my previous setup are an SB Live! PCI card (still sticking with it - it's about 10 years old, now), Antec case, and LG HD-DVD/Blu-ray burner.
I ordered all the parts on March 17, and only got everything working on April 6. Yeah, it was a little bumpy. Let's see if I can recount the whole process.
March 17. I ordered the Intel DX58SO and Core i7-980X CPU from ZipZoomFly since they gave me a combination deal, and I was weary of Newegg shipping me a fake CPU. It didn't ship until the 24th of March, though.
I ordered the video card, ATSC tuner, memory, and SSD from Newegg on the same day.
My Newegg order arrived first, on the 23rd of March. Since I figured it wouldn't be a bad idea to try out some of the components, I threw the Gigabyte card into the current Core 2 system, replacing the cheap nVidia 7600 GS that I'd been using for the last three years. It fit nicely (took up two slots since it's fanless and has a huge heatsink). The HDMI and dual-link DVI-D output worked flawlessly, and Quake 4 seemed nice and smooth.
The next step was to take the current WD 160GB SATA disk and replace it with the new OCZ 256GiB SSD. I opened the package, and was greeted by a cheap box with no papers, manuals, warranty information, or anything. I also noticed that the QC date on the back of the SSD itself said 6.1.99. That can't be right, since SSDs of this size have only been around for the last year or so.
Anyway, I went to plug the drive into a spare SATA connector, when the plastic on the SATA connector on the drive broke! It snapped in such a way that the SATA cable refused to remain connected. Total crap. I sent it back to Newegg for a replacement.
The ATSC card worked fine, though. It's much smaller than my previous one (DViCO FusionHDTV5 RT Gold) and has two tuners. I use it with a pair of bunny ears to grab 8VSB signals from Charlotte. Works great!
The DX58SO motherboard and Core i7 CPU arrived from ZipZoomFly on the 31st of March. I put it all together, noting that the first RAM slots was black, compared to the rest, which were blue. The manual said that there were three channels, but channel A was shared between the first slot and the 2nd slot:
Installing memory in Channel A, DIMM 1 may result in less than optimal memory performance.
Well, that seemed annoying, but I kept all four of them in and installed the CPU. Strangely enough, the CPU heatsink and fan did not look like a standard stock Intel model. It looked more like a 3rd-party heatsink:
Even stranger, was the heatsink installation manual seemed to indicate that the fan on the heatsink should face the power supply. This made no sense whatsoever, so I faced the fan toward the front of the case, where it would blow air through the heatsink toward the rear. After checking online, this is what most people were doing, too. I finished installing everything (minus the SSD, it was still in Newegg RMA-land at the time). After connecting everything to my existing Thermaltake 550W power supply (more on this later), I pressed the power button!
Initially everything seemed to work. The first thing I did was upgrade the BIOS to 5112, since the 4xxx version that came with the board didn't officially support the 980X processor model. After rebooting after the BIOS upgrade I went back into the setup, loaded factory defaults by pressing F9 (remember this - it's important later on in the saga), set the SATA devices to AHCI, and disabled the onboard audio so I could use my SB Live! exclusively.
My Debian GNU/Linux (w/a custom 2.6.32 kernel) installation booted up just fine via a GRUB boot disk (for some reason I can't boot GRUB from the MBR on the disk on the new system and the old Core 2 system, which doesn't bother me too much since I try to never reboot) and X started up nice and fast. I started up some music, and did a couple small test encodes with HandBrake. The system seemed wicked-fast, and running properly!
About an hour into the testing (ie, playing) MPlayer crashed, and my music stopped. I forget the exact error I saw in the kernel log buffer, but it indicated that something had gone horribly wrong with sysfs. I thought that was really odd, but continued playing around. Quake 4 then started crashing, as did almost everything else. I then fired up 6-8 copies of burnP6 (part of the cpuburn package designed to stress-test certain chipsets and CPUs heavily) and the screen went completely blank. Something was obviously wrong.
I decided that maybe one of my memory sticks was bad. I decided to run memtest86, and see what was going on. Sure enough, tons of errors on what looked to be the 2nd chip, although I wasn't certain because I'm not sure how memory is interleaved lately:
I ran memtest86 a few more times and got very inconsistent results. Some times it would show errors immediately, other times it would run for 30 minutes with no problems. I decided to go through the fun process of trying every stick by itself to narrow down the problem. I plugged in one stick and fired up 6 copies of burnP6, HandBrake in an infinite loop, and both my VMs (to use up the 4GiB) running. It had been a long day, so I hit the sack.
The next morning I find the system still running fine! RAM stick #1 was obviously working. I put in RAM stick #2 and let it run through until the next morning - worked fine, too. Unfortunately, the last two sticks checked out, too (I got lazy and only let them go for 3-4 hours each).
I stuck two sticks in (I think I used the first two slots, so they both went in channel A) and the system started to POST, then shut off! It did this a few times, then presented me with a BIOS error saying something like "the system has detected multiple POST failures" and prompted me to enter the BIOS setup. I poked around at memory settings, but really didn't know what I was doing, so I left it at default - autodetect.
I hunted around online, finding posts on Intel's site about DX58SOs dying easily, confirmed compatibility with the G.SKILL RAM modules (F3-12800CL9S-4GBRL) and the DX58SO, but didn't really find anything solid about the issue. I then ran into a few posts about instability issues caused by not enough power. I forgot that I was now running a pretty beefy CPU with decked-out RAM and a power-hungry video card. I went to Best Buy and picked out a Corsair 850 watt power supply.
After installing the new power supply, the system literally took TWO minutes to POST. Unfortunately, it seemed even more unstable than it did with the old power supply! So I threw the Thermaltake back in - and it did the same thing!
At this point it certainly seemed like something non-RAM was bad. I guessed the motherboard, and RMAed it.
I got the new motherboard from ZipZoomFly the same day I got my SSD back from Newegg (April 6). Were the stars aligning for a stable system? Well, maybe.
I threw everything together, but this time didn't populate the "black" RAM slot that would cause unoptimal performance (I learned this was roughly 5%, but I figured it may add to instability, too). Another TWO minute POST - and I got kernel panics at bootup during the USB device detection. Well, looks like the motherboard is good, but something else is bad.
I searched the G.SKILL forums and other places, and found recommendations to maximize RAM performance and overclocking recommendations, which I didn't want to do - I just wanted the system to work fine with the defaults (or baseline, etc). I began poking all around in the BIOS. In the "save changes" menu, I saw two options:
Looking at these, I wondered what was custom defaults? Furthermore, I wondered what F9 actually did, since on the main screen that just said load defaults. After loading custom defaults, I noticed that not much had changed - actually I made a change to the onboard sound (enabled it), loaded custom defaults again, and it didn't change back. Odd. I don't know what made me do it, but I hit F9, then loaded custom defaults, then rebooted. Bam - everything worked - system was stable.
I ran a few benchmarks for a few hours, and it didn't budge.
Apparently the F9 key was actually an alias for optimal defaults, which was somehow overclocking the RAM in my system. Loading custom defaults on top of optimal defaults reset the RAM/CPU timings and clock speed back to normal. I found this strange, since with both defaults auto-detect was still enabled, but the greyed-out settings were notably different. Of course, none of these options were documented ANYWHERE in the manual. Thanks, Intel!
I installed the new SSD (which still had a QC date from 1999 - what the heck?), cloned the old WD 160GB to it, and was able to keep my old Debian installation.
I decided to not take the 5% memory hit, and returned the 4th stick of RAM to Newegg. Of course I think I'm going to get hit with the 15% restocking fee when they receive it, but worse things can happen.
To get the most out of the SSD, I disabled swap, and changed the journal mode on my ext3 filesystems to data=writeback. I suppose in a crash, I'll lose some data, but it won't be as bad as ext2.
As far as benchmarking, meh, since I don't have stuff like 3DMark on Linux, I can't really do it. Here are a couple of tests, though:
% glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 100567 frames in 5.0 seconds = 20113.289 FPS 100770 frames in 5.0 seconds = 20153.916 FPS 100703 frames in 5.0 seconds = 20140.479 FPS 100628 frames in 5.0 seconds = 20125.492 FPS % sudo hdparm -t /dev/sda [sudo] password for prox: /dev/sda: Timing buffered disk reads: 696 MB in 3.01 seconds = 231.59 MB/sec % sudo hdparm -T /dev/sda /dev/sda: Timing cached reads: 18130 MB in 2.00 seconds = 9073.65 MB/sec
I also ran a few encodes from a Blu-ray source to H.264 resized to 720p. HandBrake averaged around 45-50fps. It seemed to use all 12 threads, but only at 50-60% each. Not sure why that happened, but 45fps is fine with me!
I took a boatload of photos during the build process.
I've been getting better at Quake 4, recently, now that it's finally smooth at 2560x1600 w/2x FSAA. Maybe I'll setup a server on dax, again…
The Core 2 guts will eventually move into my Windows 7 box, isis. I suspect I will have to reinstall Windows 7, in the process!
Displaying page 16 of 121 of 965 results
     |
This HTML for this page was generated in 0.009 seconds. |