They broke multicast PING in El Capitan (well, kinda!)

I've written in the past about how much I rely on the multicast PING for getting the basic network settings out of a piece of equipment (that's has come back from a customer in some unknown state). Imagine my horror when I discovered they've broken it in OS-X v 10.11 El Capitan.

 So, here's the setup, piece of gear connected directly via an Ethernet interface to my laptop (with a hard-set IP address). Ordinarily using;

PING 224.0.0.1

would force the equipment to respond with it's IP address. Then it's easy to change your laptop's IP to be on the same subnet and you're in (like Flynn). No worries that the computer and equipment are on different subnets, multicast PING forces it to respond.

It appears I'm not the only one to notice this. See here on Apple's support site.

So here's the answer; you can see the effect "No route to host", then I attach to a pocket-router with only the Amulet box on it and by attaching to it over WiFi (it's a router, no need to worry about "wrong" IP subnets) I can PING and determine the Amulet is on 192.168.6.102

I can only assume that by now having an ARP table in the way (the pocket-router) we have a source of H/W address to IP conversion. When there was just a cable between the devices and hard-set IP addresses multicast relies on the second device to answer the broadcast PING with it's H/W address in the return packet. I can only assume that OS-X 10.11 ignores that and instead does an ARP equiry of the router to match the H/W and IP addresses?

It's not a big deal as I do carry one of those little pocket routers in my rucksack as they are supper useful for lots of things;

• Isolating yourself from an (untrusted) client's network
• Isolating an untrusted machine from your network whilst working on it
• Making wired-only demo equipment wireless to aid in customer demos
• A source of IP addresses when lashing up an ad-hoc network.

Bryant's network control/measuring PDUs

http://www.bryant-unlimited.co.uk/eyepower.html

My good pal Simon Quill at Bryant has been developing this line of intelligent bay mains distribution for the last few years and I bought a couple last year and have (due to the weight of work) only just got around to playing with them. Quite a lot of manufacturers offer remotely controllable power strips with either a bit of client software or a web interface to control the various circuits. Some even offer current monitoring (typically via a shunt-resistor so you get apparent current; the heating effect, in effect!) but Bryant claims to actually measure the current via a clamp-inductor and they calibrate each circuit's 16-bit ADC prior to it leaving the factory. Simon tells me each circuit can measure to 50A to an accuracy of 1mA and they sample at 1Khz so you can see any harmonic content that is being put on by UPSes etc. 

Some of the other features;

1. Macro start-up, close sequence. You can (for example) get o/p 2 to hold off powering up until o/p 1 has settled.
2. Control of each circuit via the web interface - re-power that server?
3. Inspect the current draw (and power factory) on a per circuit basis; worried that an array of disks is starting to show odd consumption; maybe a drive is about to fail?
4. Look at the quality of the incoming mains - it's rarely a sine wave nowadays!

Simon & I intend to do an episode of The Engineer's Bench on IP controlled PDUs (not just these Bryant ones) but until then here are some screen-grabs.

 This one shows the graph for the third circuit which has an AlicePak audio balancing interface attached and is (we hope!) a linear supply and hence should be an entirely resistive load.

 This is my trusty Tektronix WFM7120 which is clearly using a switch-mode supply; notice how the current draw is when the driver transistor switches as the voltage passes a set value.

 This one shows the earth leakage current against incoming mains; a bit more sine-like but remember the effect is made worse by the presence of the Tek & the AlicePak.

This is a circuit which has no load and so consequently we're seeing the auto-ranged current draw which is just the quantised noise of the ADC.

nice!

Antrica - performance at different data rates

After my testing with the Antrica 32000AS I thought I'd better do some screen caps at different data rates; all the tests I did yesterday were at 2048kBits/sec.

32kBits/sec

256kBits/sec

512kBits/sec

1Mbits/sec

10Mbits/sec

It does seem that you don't get much benefit once you pass 2Mbits/sec - now these are only still frames and sub-500kBits you get quite a few dropped frames (I haven't figured out how to increase the buffer size at the receiver which apparently smooths this out at the expense of latency).

Finally, in an effort to get a feel for the overall degradation of HF content I grabbed a couple of frames at field-rate at each end of the encoder's range;

32kBits/sec

10MBits/sec

Antrica video-over-IP encoder/decoders

Every TV industry magazine is currently honor-bound to run a "video-over-IP will replace baseband this year" article at least once every three months. Despite the attraction of sending video over networks there are fundamental problems related not to the fact that it's a network (but, then again TCP/IP was never meant for synchronous, timely delivery of data) but rather the compression used. Actually, not the compression (after all MPEG4 v.10 variants; H.264, AVC etc are pretty good) but the latency; for long-GOP material 12-frames encode is not unusual.

I was pleased to get my hands on a couple of Antrica 32000-series encoder/decoder units. These are HD/SDi and HDMI i/o and you can configure each to be either an encoder or decoder. They are clearly based on a security camera chipset (all the Pan-Tilt-Zoom controls are grey'ed out!) but they have some very nice features;

• The outputs remain live when one is being used as an encoder so you can get a feel for what the untransmitted pictures look like (it isn't just a loop-through of the input HD/SDi). 
• They have up and down converters and so a 1080i input signal can be sent at 720P and an incoming 720P stream can be displayed at 1080i (or SD, for example).
• They have three streaming modes; their own single-port over TCP mode that streams macro-blocks and hence gives incredibly short latency; 80mS at best but more likely 200mS. A buffer at the receiver end can be wound-out to smooth the spikiness of the data rate (with the worsening of the latency). If that isn't working the units fall back to RTSP over TCP or UDP and finally if all else fails MPEG Transport Stream over TCP.
• They also do a software video-wall that will receive a dozen streams.

So, proof of the pudding and all that. I made a 1080i sequence of static frames with resolution gratings and so moving stuff. At only 2MBits/sec (which is allowed to spike-up to 3MBits/sec) I was impressed. Here is BBC HD Test-Card F straight into the monitor and then via the system;

 

The aliasing you can see on the lower gratings is from my iPhone's camera - you really can resolve them to the 15Mhz grating, so no resolution is seemingly being lost.

 These two are taken from the Belle Nuit Montage test chart which shows up all sorts of problems with resolution, colour-space and levels. The finest grating is not resolvable in 4:2:2 encoded material and so what you're seeing here is in part an artifact of the sampling structure of 1.5GBit video.

This is a screen-grab from my trusty Tektronix WFM7100 - I've parked the line-selector on that final grating and zoomed in so that we're looking at 300nS/div on the horizontal. The waveform has been faithfully reproduced with only a low-frequency (I estimate 2Mhz) harmonic. I initially thought this was a fault in the optical transfer function of the monitor but it's there on the signal.

I was playing off my laptop via a Black Magic UltraStudio Express. If you want to play with the clip I've stuck it in my useful clips folder on Google Drive (there is also so DolbyE material in there). It's also worth mentioning they have a software tool for monitoring their end-points. It's called True Manager can as well as allowing you to tweak settings etc you can also monitor in realtime the bandwidth used. This is all very encouraging as tomorrow I will stick an encoder in Root6's office and see what sort of performance I get across the public Internet. As ever with these systems they are adaptive and for still frames they settle at a very low data rate, but at scene changes the system seems to spike to around 50% bandwidth than I'd configured. BUT, the fact remains, I *seem* to be seeing very nice looking 1080i pictures over a few MBits/sec!

Photons vs. Electrons

At ten gigabits ethernet over copper cable really struggles. Everything has to be just right and even well terminated twisted pair cable is on the hairy-edge.

On the job that I've just finished had a lot of fibre and copper data and the time to test (on a per circuit basis) is much higher for copper than fibre. With OM3 fibres so long as you have an acceptable sub-3dBs of attenuation at 850nM ten gigs is a doddle. We had to re-terminate maybe half a dozen circuits and using our INNO core-alignment splicer it takes no time. On the other hand getting the copper data cables right is a mission with Near-end cross-talk, alien cross-talk and return loss all having the be measured across four pairs. The output (above) is from our Fluke DTX-1800 analyser.

As an aside, one of the freelancers I use a lot showed me a brilliant trick with fibre panels); the BT standard for core-order involves having the coloured and striped cores 12 couplers away from each other in a 24-port panel. The better way is to put the coloured and striped cores next to each other in the same duplex pair so that if you make a mistake it's easily rectified at test-time.

Amulet with the Linux Wacom driver under sub v3.8 kernel

Amulet are a great company - I believe their KVM-over-IP extender to be MUCH better than Avocent, AdderLink and ThinkLogical's offerings, but like everyone else, once you packetise up DVI and USB and send it over a network you are going to have to deal with funny effects of devices and drivers that play fast & lose with the specifications. This is from their engineering team;

Wacom tablet and Red Hat Linux has been traced to a bug in the Red Hat Linux Wacom driver. The driver has a very obvious bug in it whereby outward data is declared as inward. The Wacom tablet simply ignores this when it is connected directly, although this works it is actually because the tablet USB stack is sloppy. The rack card however cannot ignore anything else we wouldn’t be able to operate at all so it believes what the Red Hat driver is saying and waits for an event which then never happens.

As detailed below in our analysis of the Red Hat and main Linux code drivers this issue has been resolved in the latest Linux build, with the fix implementing exactly what we would expect to see. This however has not yet found its way in to Red Hat, although may do so later this year, again as per the details below.

To enable use of the Wacom tablet on the current version of Red Hat (5.3) you are using we have added a work around to the rack card firmware. It appears to work but will require testing in the lab  over the next couple of next week before we can release. The workaround has to circumvent many checks in the code that are designed to catch driver bugs just like this. As a result the workaround is very specific to Wacom devices and this exact bug so we can’t guarantee it will work if anything changes.

Red Hat 6.3 (Amulet Hotkey test version)

• Red Hat version - Red Hat 6.3 (Santiago)
• Kernel version - 2.6.32-279.el6.x86_64
• RPM package - 2.6.32-279.el6.x86_64
• Wacom driver source - wacom_sys.c
• Driver bug - Incorrect bitmask causing incorrect data direction expectation in USB driver.

Code copied below shows the addition of the correct bit mask command (in red) in the latest Linux driver

• Code in current driver - USB_REQ_GET_REPORT, USB_TYPE_CLASS | USB_RECIP_INTERFACE
• Code in latest Linux v3.3 driver - USB_REQ_GET_REPORT, USB_DIR_IN, USB_TYPE_CLASS | USB_RECIP_INTERFACE

Red Hat 5.3 (Client version)

Although versions numbers differ to Amulet Hotkey test version the Wacom driver is the same and has the same bug present

• Latest Red Hat release (6.4)
• RPM package - kernel-2.6.32-358.el6
• Wacom driver source - wacom_sys.c
• Driver bug - Still present as per RPM package 2.6.32-279.el6.x86_64

Main Linux code base

• Version - v3.2.45
• Driver bug - Present
• Version - v3.3
• Driver bug - Resolved

Future Red Hat 

• Wikipedia gives the time frame for the next major RHL release (7.x) as Q3/4 2013
• We can't be sure whether this would incorporate the fix to the Wacom driver however Wikipedia states "Red Hat Enterprise Linux 7 (?), 2013-6+ Will be based on Fedora 18,[17] which as of March 2013 uses Linux kernel 3.8.[18]". This would indicate that the upcoming release of Red Hat 7 will fix the issue, as it will use a newer kernel, v3.8