content top

Diggnation Comic-Com

Diggnation Comic-Com

San Diego’s Diggnation fans were in for a treat this Friday, when Diggnation Episode 55 was taped in front of a live audience at the La Jolla Brew House.
Thanks to the Comic-Con Convention, which is also happening his weekend at the San Diego Convention Center, the whole crew, including Kevin Rose,

Alex AlbrechtKeith HarrisonDavid Prager, and Jay Adelson showed up.
Taping took place in a back room at the brew-house, in front of what must have been the biggest diggnation live audience yet. Spotted in the audience were some very special guests, including Alex’s grandparents and Posh from the suicide girls. As always, the guys were really funny and the crowd almost exploded when Johnny Johnny from the TikiBar podcast made a brief appearance, serving some hight voltage beverages.

Alex Albrecht & Kevin Rose

Alex Albrecht & Kevin Rose

Suicide girl Posh

Carlsbad Cubes' Dr. T.C.P.

Alex, Kevin, and TikiBar's Johnny Johnny

Alex Albrecht

Alex, Kevin, David Prager, Johnny Johnny, and Posh

Alex Albrecht & Carlsbad Cubes' Dr. T.C.P.

Read More

Data Transfer Speeds Compared

When it comes to file transfer over your local area network, Wifi and Bluetooth win hands down, when only “coolness” is considered. Obviously, the laptops at my house share files using their built-in Airport Extreme cards, but all other computers are connected through a“legacy” 100 Mbit Ethernet Switch (DLink DSS5+) and that is also the case for Tom’s Mac Mini.
It would take some serious work to convince him that a plain old CAT5 Ethernet cable really has its advantages, even if it meant not being one of the 802.11 cool kids.

We started looking into all the different ways in which we can share (or at least transfer) files between computers.

  • Ethernet
  • Firewire
  • Wifi
  • Bluetooth

All these networking options have different advantages and their preferred applications. However, we were only looking as one thing: transfer speed, how fast files could be moved between computers.

To establish a point of reference, we looked at the time it took to copy 10 megabytes and 100 megabytes locally on the G5 PowerMac.
Since we knew that there is a lot of buffering going on, we decided on the following set of rules for all our tests:

  • Source and destination location is on the same hard-drive, meaning during a copy-operation, data is sent up and down, effectively doubling the payload.
  • Each test is performed at least 5 times.
  • We take only one result, the best one.
  • We keep on performing the same test, until there is no improvement in three consecutive tests.
  • Only absolutely necessary devices are connected to devices participating in the test
  • Only absolutely necessary applications are allowed to run during a test.
  • All security features (including WPA, WEP, Radius, etc.) are disabled during all tests.
  • During the Wifi tests, the laptop is operated about two yards away from the router and iStumbler is used to verify a high quality connection

Gigabit Ethernet

Since we didn’t have any 1000BASE-T enabled switch or router, we connected two computers with a straight-trough CAT5 cable. The Macs are equipped with auto-mdix network interfaces, allowing us to connect two machines directly, without the need for a crossover cable. However, 1000BASE-T requires all four pairs of a CAT-5 cable to be present.

4-pair vs. 2-pair CAT-5 Cable

Unsurprisingly, with a measured 614 Mbit/s, Gigabit Ethernet scored the best result in all tests. The 100 MByte test file was copied back and forth in about 2.5 seconds.

Megabit Ethernet a.k.a. Fast Ethernet

100BASE-T Ethernet is what we usually use on the LAN at home, since all switches and router are able to handle this standard. However, to comply with our test rules, we didn’t use any of those and again used a direct cable connection to perform the related set of tests.
The result (152 Mbit/s) came in much better than expected, which may be due to the OS buffering some of the transferred data. The 100 MByte test file was copied back and forth in about 10 seconds.

Firewire 400

Both test machines were equipped with Firewire 800 and Firewire 400 ports. Unfortunately, we could find a Firewire 800 cable and therefore only Firewire 400 was tested.
Setting up a TCP/IP network over Firewire is pretty straightforward. Again, a direct cable connection was chosen and IP addresses were manually assigned.
Like we had expected, the Firewire-400 result (288 Mbit/s) was somewhere between Gigabit and Fast Ethernet but a little slower than anticipated. The 100 MByte test file was copied back and forth in about 5.5 seconds.

Cutting the Cord

Now that we knew how fast we could copy data locally and over all sorts of wires, it was time to cut the cord and focus on some more fashionable networking options. Among the several wireless routers we used in the test was the new tiny Linksys WRT54GC, a Wireless-G (802.11g at 54Mbps) and Wireless-B (802.11b at 11Mbps) devices with built-in 4-port full-duplex 10/100 Switch, measuring only 3.86″ x 3.86″ x 0.98″ (98 mm x 98 mm x 25 mm) W x H x D.

Linksys WRT54GL (Firmware v4.30.5)

Unsurprisingly, this conventional and widely used wireless router performed best among the wireless options.
We measured up to 48.23 Mbit/s and the 100 MByte test file was copied back and forth in about 32.5 seconds.

Linksys WRT54GC (Firmware v1.02.8)

Not quite as fast as its big brother but still very much inline with expectations was the transfer speed of this cool little device. We measured up to 35.48 Mbit/s and the 100 MByte test file was copied back and forth in about 50 seconds.

Netgear WGR614v6 (V1.0.11_1.0.7NA)

The stylish white Netgear router performed surprisingly not inline with our expectations and came in last, with only 25 Mbit/s. The 100 MByte test file was copied back and forth in about 1 minute 2 seconds.

Bluetooth

Not really fair – still, we couldn’t resist to find out how long it would take us to transfer the files via Bluetooth. However, after performing the tests with the smaller file (10MByte) we concluded that we didn’t really needed to copy the 100 MB.
The Bluetooth test showed a transfer rate of about 0.5 Mbit/s and the smaller 10 MByte file was copied back and forth in about 5 minute 14 seconds.

Read More

Cable Modem Signal Levels

If you have a router to connect multiple computers to your high-speed Broadband Internet connection, your certainly have configured the router’s DHCP and NAT settings, using a networked computer’s Web Browser. On a LinkSys router for instance, this is done by browsing tohttp://192.168.1.1. You can also use your Web browser to find out how good your cable connection is. The magic address for most cable modems ishttp://192.168.100.1, some models may require http://root:root@192.168.100.1.

Now, you may immediately have recognize that this address as a non-routeable IP address, which means that we either have to connect a computer directly to the cable modem or hack the NAT-router’s routing table. Never, ever, should you connect a Windows box directly to the Internet. Personally, I don’t even want to do it with my Macs or Linux systems.

Routing non-routeable IPs

To allow a computer on your LAN to access the cable modem’s internal Web server at 192.168.100.1, we need to enter a route, to permit your router to pass traffic through, to a non-routeable IP address. Find out what your router’s IP address or its Default Gateway‘s IP address is – the router’s status page should have this information and the IP usually starts with 67 or 68.

Find your router’s advanced routing settings page and enter a new route like this:

Route Name : CableModem
Destination LAN IP : 192.168.100.1
Subnet Mask : 255.255.255.255
Default Gateway : (enter your cable modems’ or its default gateway’s IP)

You should now be able to get to the info-page in your cable-modem and find out how good your connection is. Now, with good I don’t necessarily meanfast, but we get to look at Downstream Power, Upstream Power, and Signal to Noise Ratio (SNR) levels.

Downstream Received Power

For a DOCSIS cable modem to work within the specification, the Downstream (or Received) Power level needs to be in the -15dbmV to + 15 dBmV range. The desirable signal level would be -6 dBmV to -3 dBmV.

Downstream Signal-to-Noise Ratio

The downstream SNR tells how much noise is on the cable. Again, for the cable modem to work within the specification, the SNR needs to be at least 23.5dB; a desirable ratio is 30 dB or higher.

Upstream Transmit Power

The cable modem’s Upstream (or Transmit) Power needs to be in the +8 to +58 dBmV range. However, the better the return path is, the lower the upstream transmit power needs to be. Meaning we are looking for a value well below 50 dBmV.

Poor signal levels will lead to frequent packet loss, your router not being able to obtain an IP address from the ISP’s DHCP server, and spontaneous cable-modem rebooting. However, if the signal levels are not that great, don’t blame your cable provider yet. 2 or multiple-way splitters may be responsible for your weak signal as well.

Putting a splitter before the cable modem, without even attaching any additional devices like a TV or VCR, had a strong negative impact on my signal:

Downstream: -1.9 dBmV :: -6.9 (with splitter)
SNR: 35.6 dB :: 34.4 (with splitter)
Upstream: 41.5 dBmV :: 46.8 (with splitter)

Read More

How to remotely access a Mac behind a corporate firewall

How to remotely access a Mac behind a corporate firewall

Accessing your Mac remotely isn’t really that difficult, if it weren’t for your resident IT-Department. You could simply open System Preferences / Sharing, enable ARD (Apple Remote Desktop) and check the VNC viewer checkbox. By doing so, your Mac starts listing on port 5900 and you could access it via any VNC viewer, like Chicken of the VNC (for the Mac), or RealVnc, or TightVnc (on Windows).

VNC is one of the very few – if not the only – cross platform solutions, allowing to access a Mac from a Windows box or vice versa. However, opening a server port is usually unacceptable and not tolerated by your IT folks – for a good reason, I might add.

OSXvnc to the rescue

Fortunately, there is the OSXvnc open source project, while providing only a subset of Apple’s ARD, it has the nice feature, allowing the server to make the initial communication request.
Usually, you open port 5900 on the machine you would like to remotely control. That machine starts to listen for request from a vncviewer, on the predefined port. In this case, like with almost all clients, the viewer initiates the communication.
OSXvnc allows you to enter an IP address and by clicking the Add button, let the vnc server call the client (the vncviewer). Obviously, to make this work, the vncviewer would have been started in listening mode on the machine with the given IP.

Now, there is a little problem that still needs to be resolved: OSXvnc needs user interaction (clicking the add button), to make it initiate the connection. A really short shell script installed as a daemon however helps us to work around this issue.
To make it clear how this all works, lets create a common scenario:
A PowerMac G5 that we want to remotely control is located in the office, behind a tight corporate firewall.
A laptop we want to use as the controlling machine, runs OS X with Chicken of the VNC installed, or Windows with a VNC Viewer.

Lets start on the server-side by installing OSXvnc on the G5.
The next things we need to do is find a port that is open for outbound traffic. Some companies have all ports above 1024 open for outbound, outhers are more restrictive. However, usually there are some ports left open. E.g., if you can browse the Internet, port 80 is open for outbound traffic. To continue with our common scenario, let’s assume port 8200 would be open for outbound traffic.

The remaining part of the information-gathering phase is to find out about your IP address at home. This IP and the outbound port will have to be configured in this shell script:

#!/bin/sh

#

# OSXvnc-server polls client

#

#

# Path to server application

#

OSXVNC=/Applications/OSXvnc.app/osxvnc-server

#

# VNC-Client’s IP address

#

CLIENT_IP=207.46.130.108

#

# Port VNC-client is listening on

# e.g. VNC-client is started on Windows with: C:\>vncviewer -listen 5901

#

VNC_PORT=8200

#

# if we are currently not connected:

# kill previously launched server app and try to poll client.

#

lsof -i:$VNC_PORT | grep -q ESTABLISHED

if [ $? -ne 0 ]

then

killall osxvnc-server

$OSXVNC -connectHost $CLIENT_IP -connectPort $VNC_PORT &

fi

exit

The script simply checks if there is currently an established connection on the predefined port, in which case it would do nothing. If there isn’t a connection going, it first kills any previously started OSXvnc processes and then trys to initiate a connection on the predefined port to the predefined IP address.

We install the script in a place like /Library/SysScripts on the G5 and don’t want to forget to give it execute rights.
The last thing that remains to be done on the server, is to deploy this script as a daemon and make it execute frequently. Tools like lingon are great for doing this. Here is the descriptor I ended up with in /Library/LaunchDaemons, which polls for a client every 15 seconds.

<?xml version=”1.0″ encoding=”UTF-8″?>

<!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>

<plist version=”1.0″>

<dict>

<key>Label</key>

<string>VNC Connection Initiater</string>

<key>ProgramArguments</key>

<array>

<string>/bin/sh</string>

<string>/Library/SysScripts/cc.sh</string>

</array>

<key>ServiceDescription</key>

<string>Trys to connected to predefined IP</string>

<key>StartInterval</key>

<integer>15</integer>

</dict>

</plist>

Find out more about launchd, what it does and where to deploy the descriptors here: http://developer.apple.com/macosx/launchd.html

After this is done, OSXvnc trys to call your home IP address on the defined port every couple of seconds. All what is left to do now is forward the request from your Router at home to your laptop and start your vncviewer in listing mode.

How to forward a port (8200 in our example) to your Laptop, depends pretty much on your router. In any case, since OSXvnc sends the connection request, we need to make sure the calls arrive at machine running the vncviewer. Last thing left is starting the vncviewer. Windows folks do this via the command line, like
vncviewer -listen 8200

Mac users using Chicken for the VNC, use the GUI.

No later than 15 seconds after starting the viewer in listening mode, you will look at your office-computer’s screen …

Read More
content top