Windsong B&B where we stayed on the east coast of Tasmania.
I decided it was time to reboot my digitalocean machine after installing a new kernel. Its uptime was:
17:14:28 up 368 days, 19:55, 3 users, load average: 0.29, 0.10, 0.07Since that's a year I suppose that in that time it's cost me about $60, minus some for the referrals I've gotten for posting about them on my blog.
.. I actually had to reboot it twice because I didn't know you had to change the kernel version via the control panel(!) but no harm done.
Anyway, in that time I never noticed any blips in functionality or connectivity, though on a couple of occasions they credited me a few cents for a service interruption.
All in all, it's quite a solid service!
TXRX Labs of Houston opened its doors to LinuxCNC users and developers.
I was there from Friday to Tuesday, and enjoyed the time talking to fellow users and developers.
On the development side, we brainstormed and then started work on what we are calling "lui", a new C API for developing LinuxCNC user interfaces. lui is the first step of an incremental plan to eventually remove NML, or at least make it optional. I also investigated a proposed fix for some long-standing multiple UI fixes, which I think we should incorporate in 2.7 even though it needs further work to support the near-mythical NML-over-TCP connection method.
Seb volunteered to be the release manager for 2.7, we accepted his offer, and he created the 2.7 branch, which should now be considered to be in a stabalization phase.
As far as TXRX's retrofit projects, a bunch of us worked on the "Powerhawk". A fair amount of time was spent chasing problems with the servo motor tuning (causes included ground loops and generating correct simulated tachometer feedback), but we also got all home and limit switches working and started troubleshooting the partially-done tool changer implementation.
On the education side, we did not do as much as we had hoped to do. I had prepared a very introductory talk on writing hal components with comp/halcompile. However, everybody with an interest in writing hal components already knew everything in my presentation, so there was little point in actually giving my talk. Jon Elson did use the Powerhawk as an object lesson in servo tuning.
On the social side, it was fun to hang out with fellow LinuxCNC people, as well as meet and talk to the TXRX locals. Everyone was quite friendly, and I got to give the "elevator pitch" LinuxCNC introduction to a fair number of people. Chris and Roland were great hosts, too, making sure we could come and go at all hours.
I would love to return to TXRX labs for a future LinuxCNC gathering. Hopefully that would include a little more structure (such as setting a schedule for presentations, in case that helps bring in more people who would benefit from them). One interesting idea I heard was getting some simpler (bridgeport-scale) machines to retrofit with LinuxCNC, which would then be given (back) to other hackerspaces when we were done.
(more photos of TXRX labs after the jump)
Update, 2014-10-25: This can be mitigated on the server side. When HTTP headers specify 'Cache-Control: no-transform', Sprint's proxy honors it and doesn't degrade the image before sending it to the phone. In apache, this can be achieved by enabling mod_headers and putting Header add Cache-Control no-transform in an appropriate location. I've done this for the server where my photos come from...
When showing my blog photos on my phone, I noticed that they looked terrible. Shown above is a detail of the original image (not entirely free of JPEG artifacts) and of the same area after it was recompressed by sprint. (zoomed 200%, nearest neighbor scaling)
It turns out that sprint recompresses jpegs and this is documented by sprint, but it's still terrible.
It also affects ting.com users, since they are a sprint reseller. (and I didn't find any ting documentation about this misfeature yet)
This happens both on the phone itself, and to devices tethered via the phone.
Most images aren't mangled quite as badly as this one, but their claim that there's "no user perceptible loss of quality" is bunk.
Here are the jpeg files zipped up, in case you are interested in inspecting them for the jpeg compression details: original-and-recompressed.zip
I know that serving web pages over https is the new hotness; here's another reason to do it, since sprint couldn't rewrite the contents of content served over https.
Original image, converted to png
Sprint-recompressed image, converted to png
Halls Gap Zoo, not far from Horsham.
A few months ago I moved most of my web presence to Digital Ocean. With the cheapest instance costing $5 a month, this beat my former provider dreamhost.com (at about $9 a month for shared hosting), while offering much better performance.
Digtal Ocean (and VPS hosting in general) doesn't offer the "unlimited everything" of dreamhost's shared hosting plans, but the $5/month VPS has more available CPU power (which means pages get served faster) and it has enough space to host all the photos and blogging I've posted online for about 13 years.
When I chose Digital Ocean, one of the main reasons I picked them over hosts like linode.com was that their cheapest hosting plan was lower in price. For price points where Digital Ocean and Linode overlapped, their offerings were about the same in CPU, memory, and storage.
Enter Atlantic.Net. They offer a VPS at the $0.99/month price level. It has less RAM and less disk than Digital Ocean's $5/month instance, but it's still enough to run a substantial website (256MB RAM, 10GiB disk). I decided to try it out, because one of the websites I run is a moinmoin wiki, and that software is perhaps high-profile enough to see security exploits (as opposed to my blogging platform, which nobody's heard of or uses). So yesterday I moved that website from Digital Ocean to Atlantic.net.
I decided to run some tests using the simple 'ab' benchmarking program. All tests reported below were run with '-n 100 -c 4', and I report the 95th percentile time in milliseconds (so smaller is better).
My Digital Ocean instance is in the nyc2 region, and my Atlantic.net instance is in the USA-Central-1 region. I ran tests from each cloud server as well as from windstream and roadrunner in Lincoln, Nebraska, USA.
|Static content||Dynamic content||Static Content||Dynamic Content|
|Digital Ocean||1 ms||124 ms||100 ms||1093 ms|
|Atlantic.net||100 ms||2091 ms||1 ms||59 ms|
|windstream||104 ms||1823 ms||46 ms||1133 ms|
|roadrunner||415 ms||2154 ms||73 ms||1158 ms|
While there's probably a great deal of measurement error in there, it looks like overall Atlantic.net's faster—both in CPU speed, which is why locally generating dynamic content is faster than on Digital Ocean; and in connection speed to where I am. But that may well just be a matter of where the datacenters are, as Lincoln Nebraska sounds closer to "USA-Central" than "NYC".
Other differences that could influence performance: the Digital Ocean instance is running Debian Wheezy and the Atlantic.net instance is running Debian Jessie.
Other points of comparison between Digital Ocean and Atlantic.net:
- I like the Digital Ocean control panel better
- Digital Ocean has a referral program so I've gotten several months of service free.
- My tests were very simplistic, and done at one time of day, with no control over the other load on the systems in question
- Unintentionally, some of the Digital Ocean tests from roadrunner went via an IPv6 tunnel which can negatively affect performance
Which hosting should you choose for modest hosting needs? Start by trying Digital Ocean with my referral code—you are receive a $10 credit, enough to run their smallest instance for two months, and I get a credit too. If you're incredibly budget minded, or want the slight edge in performance that I am measuring, try Atlantic.net instead and get VPS hosting for as low as $0.99 a month.
Kingfisher Cruises. It was a fun trip exploring a shallow river area with a wide mix of birds.
All older entries
Website Copyright © 2004-2014 Jeff Epler