Older blog entries for Grit (starting at number 17)

Eugene Volokh does an excellent job explaining why John Ashcroft's "obsenity crackdown" is doomed to failure, tyrrany, or both.

Not that that's stopped the "war on drugs".

I do wonder, however: Could a P2P service be hit with obscenity charges more easily than copyright violation? "Substantial noninfringing use" is a copyright defense, not necessarily one for obscenity--- but then, I'm not sure there's a "contributory obscenity" charge anyway.

Rant:

So, boingboing is having problems paying their "bandwidth bill", and are asking for suggestions on how to raise some cash. In addition to all the usual suspects (sponsorship, tip jars, advertising) there are more than a few suggestions that some sort of P2P technology should be developed to help distribute this content. (Or that they ought to use an existing one.) I like boingboing, but I hate P2P. Hence the following rant.

P2P does not solve server networking costs. Let's ignore UI issues, reliability, security, etc. At the end of the day, N bytes have to be transferred from one computer's uplink to another computer's downlink. (There are certainly advantages to how far across the Internet you have to travel, but nobody I know is charging based on that.) Somebody, somewhere, is paying to send traffic onto the network.

But, you might say, my uplink is idle most of the time. True; most users produce just a small amount of upstream traffic under 'normal' workloads. But there's no free lunch here--- if your upstream provider has any brains at all, they've already taken that into account in engineering their network. Widespread change in user behavior leads to changed costs for the ISP, unless the P2P application is extraordinarily good at reducing wide-area traffic. The ISP has two choices when their costs go up: they can charge more, or they can limit service. Most ISPs appear to be taking the latter route, although some try to push P2P users into a higher-priced plan.

In the long run, wide-area P2P applications will be either squelched by traffic shaping or subsidized by increased connectivity costs. A P2P-friendly ISP almost certainly sends more traffic onto the wide-area Internet than a P2P-limiting ISP, and thus incurs a higher cost structure. The "bandwidth" costs are spread across the P2P-using population at large rather than levied on the operators of a particular service. It's not obvious to me that this is an economic good (or a social good) compared with paying for the services you want the normal way--- subscriptions, ads, or donations.

This is not to belittle the very real problem BoingBoing is facing; maintaining web content or services in the face of increasing popularity is hard for anybody, even those explicitly trying to make money from it.

Fun:

I ordered some more Delcom USB I/O chips. I'm assembling my own USB-based PIC programmer based on the Delcom part for control and a National Semiconductor LM2585S-ADJ to generate the programming voltage. (The PIC12F675 just uses this as a level indicator, and the PIC16F877s can be programmed at normal voltages, so this device is somewhat overkill.) Unfortunately I picked up the wrong type of ZIF socket on my last trip to Silicon Valley (it can't take 0.3" parts) so I need to find a replacement.

In the long run, it might be worth adding a microcontroller so that the USB communication is less overhead. My current design bit-bangs the programming protocol--- somewhat slow at 3 USB commands per bit!

Work:

Been chasing TCP performance problems. We're sending lots of data over a Gigabit Ethernet switch. Unfortunately TCP's timing parameters are tuned for the wide-area; it's ridiculous to wait 500ms for SYN ACK and have a minimum RTT of 200ms when the other end really is less than 1ms away. Having a 1MB transfer sometimes be 11ms and sometimes be 211 ms or 511 ms is no fun.

Fortunately we're using Linux, and we're in a situation where we can just change the constants and recompile. Or, if necessary, we can use a different transport protocol--- but TCP seems to be good enough if tuned. (It's understandable, if a little annoying, that these numbers are compile-time #defines rather than dynamically adjustable variables.)

Fun:

I got a bunch of sample microcontrollers from Microchip and have been playing around with them. I wrote my own programmer (adding yet another to the hundreds out there) and have only ruined one chip so far due to getting +5V and +12V switched around...

I've using gpasm from gputils as the assembler; it's a well done open source tool.

My I2C "logic analyzer" is complete; I put a couple new pictures on my electronics page. My soldering skills have yet to noticeably improve.

Shopping:

I visited a couple more electronics stores in the Minneapolis area today. AEI Electronics was a little disappointing; they have a lot of audio stuff, but not many parts out and available. Even IC sockets were in the employee-only area; I prefer being able to look at what I'm getting. Plus they overcharged me for the sale items I got but didn't charge me for my resistors.

Midwest Electronics was about what I expected; they do mainly old computer stuff. I restrained myself from buying one of the stack of Sun workstations for $10. I did find a tube of 18-pin DIP sockets which didn't have a price tag, so they let me have it for free.

So it looks like ABC Electronics is the best so far--- unfortunately they're not open on weekends.

I put up a web page with pictures of my pitiful, pointless electronics projects. Oh, well, at least I'm having fun.

I have gained an amazing amount of respect for capacitance. Virtually every problem I've had has been solved by adding more capacitors.

I'm looking for a good microcontroller to start playing around with. I've been thinking of Microchip's PIC12F629/675 series, since they're (1) flash-programmable, (2) dirt cheap, and (3) have an inexpensive programmer: the PICkit "flash starter kit" ($36). I love living in the future--- who would have predicted you could get a 5 MIPS, 8-pin computer for under $2.00?

But, I would need to buy quite a bunch of them for the project I have in mind and link them together, which is a nontrivial exercise. Or maybe I'm just a wimpy, cushioned C++ programmer who just can't handle having only 64 bytes of RAM. :)

I have a couple of samples of the Dallas Semiconductor DS80C400, but no eval board. I really like this chip--- it's got onboard Ethernet, although it needs an external PHY and transformer which I don't have yet. It can net boot, which is my ideal in terms of programmability. (This is probably not a reasonable possibility, since I don't want to have to solder the LQFP package, unless I buy one of the pre-made modules.)

Any Advogatans have experience to share with either of these, or can suggest a favorite which doesn't require large up-front costs?

I've been playing with a Delcom Engineering USB I/O controller. USB just makes me happy--- control + power together, so no wierdo serial bit-banging or parallel printer connection necessary to interact with electronics, and no $$$ for a power supply.

I started out using Thomas Hargrove's libdelcom, but I wanted a more convenient interface. So, I've written a C++ library called libdelcom++, which I released last night under the GPL. (Woo! First freshmeat entry!)

I'm working on a companion library for talking to I2C devices.

P.S. SWIG rocks. If only it handled nested classes.

Wow, more than a year since the last entry.

The company I'm working for, Kealia, is being bought by Sun. I have mixed feelings about this, but on the whole it's a good outcome. Working with Andy Bechtolsheim has been an amazing experience.

Here's the only story I'm allowed to tell about Kealia. I've learned the hard way to never, ever contribute patches to an open-source project using an email address you care about. I submitted a two-line patch to VideoLAN using my work email address. They very kindly put me in their thank-you list. As a result, every email worm which scans local files for email addresses ends up dumping thousands of emails into my account. (MyDoom passed the 36,000 mark a couple days ago.) procmail can only do so much by itself...

(Yes, yes, I should be using Bayesian filtering, and I do at home. It's the disproportionate penalty that annoys me--- this email address appears virtually nowhere else outside of Kealia.)

I'm annoyed enough with the SBC ads about "we built the network and understand it, don't force us to let other people use it." But now that they're offering long distance, the "one bill" commercials make absolutely no sense.

I already get one telephone bill with both local (SBC) phone service and (Sprint) long distance. What are they trying to convince me of? Do they think I'm too stupid to know how many bills I'm paying? (I may be paying extra to have SBC bill me, but I could save $1/month by having Sprint bill directly to my credit card if I cared.)

The Star-Tribune hit the nail right on the head in their editorial about "kids.us." The question to ask is: who will use this? Who will it benefit? Certainly anybody doing Internet filtering today is not going to add "*.kids.us" to their whitelist. (Although if somebody announces such a plan I'd be interested in hearing about it.)

I'm annoyed that from a government perspective, 12-year-olds and 7-year-olds are equivalent in what they should be allowed to see.

I'm also worried that the failure of ".kids.us" would increase the pressure for a worse "solution", like a ".xxx" or ".prn" domain. Not that they would work, either.

lukeg: I appreciated your comments on TCP. One of the members of my research group (Sam Liang) is doing his thesis on "using TCP for everything". One of his papers, on extending TCP for multicast support, was accepted at Infocomm 2002.

The work is in some ways a reaction to all the numerous wierdo protocols people build--- either explicitly or in an ad-hoc manner on top of UDP. A lot of times people set out to roll their own and end up duplicating a lot of TCP's features that they initially thought they didn't need. There is also a very real sense that TCP might be the only protocol we get to use; anything else is going to be even harder to deploy, harder to get through firewalls, might not be allowed by router ACLs, doesn't work with NAT, etc.

Real-time delivery is the biggest problem people seem to have with TCP. (Unless they're trying to load up their entire multi-gigabit link with a single TCP flow...) Sam's design provides a way around this, that is probably good enough for most applications. Check out his TCP-RTM paper if interested.

Framing is a big issue; the approach we've been thinking about lately is to use application-layer framing (which is necessary for the reasons you mention), but to change TCP's behavior to respect write() boundaries. Thus, an individual TCP segment (and a read()) contains bytes from no more than one application-layer frame.

I think you've nailed it on the head about "Worse is Better": TCP may often be not quite the right thing from an end-to-end perspective, but it's so much easier (and better engineering) to use what's already there than try to come up with something better from scratch. I'd argue (donning my asbestos suit) that the same thing can be said about IPv6 and NAT: one looks better from an e2e perspective, but a solution which just fixes NAT's problems will be a lot easier to deploy (and not necessarily violate the e2e argument, either.)

*sigh* So much verbiage, so little code.

I finished editing my papers on domain name policy for the class I took this spring. They're up here in a variety of formats. One still to go.

I also wrote a medium-cool short paper on denial-of-service attacks against the domain name system, which I submitted to HotNets. Not going to make that one publicly available for now, but if you're interested, drop me an email.

Congratulations to Marissa, whose short story "The Handmade's Tale" is an honorable mention in the 2001 Year's Best Science Fiction anthology!