Friday, 3 August 2018

Shoehorning Duallies - The Lenovo C30

Just picked up a Lenovo C30 from ebay, which looks like at least one company thinks like me as far as cramming a lot into a small case. In this case, a more or less EATX dual Socket 2011 motherbard in a case rather smaller than a regular PC case.

I'll be going into this into a bit more detail in a later posting but first a few observations:

  1. The BIOS was rather old and Lenovo has done quite a good job at releasing regular updates to cover Intel's security holes - both in the Management Engine firmware and the whole Meltdown/Spectre debacle. However, the CDROM-based EFI BIOS update failed - judging from the error message, the EFI code on the board was too old to run the update script. So I go to use the DOS update using a Rufus generated bootable USB key - I'm running Linux on this so the Windows update was not an option. This gave me an out-of-memory error which was somewhat annoying - fortunately the error message was accompanied by the command line that flash.bat was trying to execute. Entering this manually, without the overhead of and Lenovo's wrapper code, worked fine.
  2. The motherboard is identical to the considerably larger Lenovo D30  but with half the RAM slots missing (8 instead of 16) to allow better airflow - the D30 has RAM cooling fans but the S30 relies on passive airflow. However, I think that a D30 motherboard would work fine with all the slots if I stick to low voltage DDR3L. If one comes up for a good price I may try that. As it is, 16GB DDR3 DIMMS are getting quite cheap on ebay and 128GB is probably enough.
  3. The C30 is quiet - even with all the cores maxed out running SETI it hardly makes any sound.
  4. There are several versions of the C30 and early ones, the 10xx series, don't support Ivy-Bridge Xeons but the 13xx series do. Most sellers don't distinguish and, frankly, if they're just shifting the boxes that they have, then I wouldn't expect them to know. Lenovo's documentation isn't the clearest on this either. I bought one with dual E5-2609 v2 chips to ensure that it was the right version - and then promptly swapped the CPU's for something less feeble. 
  5. I'm waiting for the more beastly e5 v2 Xeons to come down a bit in price. In pairs, they hold their own against current single socket cpu's in multithreaded benchmarks rather well. I suspect that this is because multithreading tends to be memory constrained and a dual 2011 platform has 8 channels of DDR3 which isn't bettered by todays Epyc and Xeon Gold's. While they do give up a bit in bandwidth (DDR3 1866 vs DDR4 2666) the latency is amost the same - which counts for a lot as thread numbers and consequent randomness of memory accesses rise. 

Thursday, 19 July 2018

Intel Quad Port PRO/1000PT and PCI-E revisited

I was really annoyed that I had to put the Intel Quad Port PRO/1000PT right next to the video card in my new build since it wouldn't work in a PCI-E 3.0 slot - and, in fact, would stop the machine from booting if inserted. That was making the video card 5-10C hotter since it was passively cooled and needed a bit of air circulation.

So I dove into the BIOS and found that I could set the PCI-E version for the PCI-E 3.0 slots (but not the 2.0 slot for some reason). This could be just the thing - so I set the problematic PCI-E slot to PCi-E 2.0 mode, remembering that Supermicro still numbers the slots as if the PCI-X slots that aren't there on the X9SRI are still there, and moved the network card over. Lo and behold! The machine booted.

Unfortunately, this was as a result of the network card just not working at all, as opposed to actively stopping the boot process. Obviously there is a subtle difference between a PCI-E 2.0 slot and a PCI-E 3.0 in 2.0 mode - remember, this is an Intel network card in a motherboard with an Intel CPU and chipset. Moderately unimpressed with both Intel and the mess that seems to be PCI-E standards.

A search for Intel documentation reveals that the low profile PT-cards are actually PCI-E 1.0a (which I wasn't aware even existed) which should work with PCI-E 2.0. Finding this was a lot harder than in the past as Intel seem to have expunged or broken links for older products. I remember when they used to have really good legacy support not so long ago (i.e. 18 months!). So I drop down to PCI-E 1.0 in the BIOS and finally everything works OK.

Outcome, a cooler, working system and increased disillusionment with Intel and the whole PCI-E mess. PCI/PCI-66/PCI-X either inter-operated or was keyed so you couldn't make a broken configuration - this is not progress, guys!  

Monday, 16 July 2018

Mobile Device Table

A summary of the portable computing devices that I have used for work over the years for no reason other than general interest. There are others (such as the Omnibook 600C) that I have owned and toyed with but not used in anger.

The heaviest device was the AST Ascentia J30 at 2650g, a large chunk of which was battery as far as I can remember. The largest screen was the Dell XPS 13 Developer Edition which, with Linux out of the box, was a real delight apart from the trackpad.

I don't get on with trackpads of any sort (yes, I've tried Macs and I find they're even more annoying than PC ones). The Omnibook popout mouse was a great idea, trackpoints are fine and touchscreen are OK provided they have stylus support. The Samsung Tab S is interesting - it has a capacitative screen but works with a special Samsung stylus with a narrow tip. I don't know how they do it since the stylus won't work on other screens.

Mfg Model Year CPU RAM Storage Screen Size Screen Resolution
Casio FX 700P 1983 Hitachi HD61913A01 2K 12K ROM ~2 inch 12 chars
HP Omnibook 300 1993 Intel 386SXLV 16Mhz 4M ~12M ROM
9 inch 640x480 (16 grey levels)
AST Ascentia J30 1996 Intel Pentium 133MHz 40M 800MB HDD 10.4 inch 800x600 DSTN (256 colours)
HP Omnibook 800CT 1996 Intel Pentium MMX 166MHz 80M 2G HDD 10.4 inch 800x600 TFT (16 bit colour)
Fujitsu Lifebook B2154 2000 Intel Mobile Celeron 450MHz 192M 2G HDD 10.4 inch 800x600 TFT (16 bit colour)
Sharp Zaurus SLC1000 2005 Xscale ARM 416MHz 64M 128M SSD 3.7 inch 640x480 ICZ
Fujitsu Lifebook U810 2007 Intel A110 800MHz 1G 60G HDD 5.6 inch 1024x600 TFT
Toshiba NB100 2009 Intel Atom N270 1.6Ghz Hyperthreading 2G 120G HDD 8.9 inch 1024x600 TFT
Dell XPS 13 L322X 2013 Intel Core i73537U 2GHz (3.1 turbo) Dual core+HT 8G 256GB SSD 13.3 inch 1920x1080 IPS
Samsung Galaxy Tab S 8.4 2014 Exynos 5420 Octa 3G 32GB + 128GB MicroSDXC 8.4 Inch 2560x1600 OLED
GPD Pocket 2017 Intel Atom X8750 1.6GHz (2.56GHz turbo) Quad core 8G 128GB SSD + 256Gb MicroSDXC 7-inch 1920x1200 IPS

Mfg Model Year HxWxD (mm) Mass (g) Touch-screen Track-point Conver-tible Notes
Casio FX 700P 1983 71x165x10 116

BASIC Programmable Calculator
HP Omnibook 300 1993 163x282x36 1315

MSDOS 3.3, Windows 3.1, MSOffice in ROM
Popout mouse
AST Ascentia J30 1996 289x228x47 2650
Win 95
HP Omnibook 800CT 1996 185x282x40 1770

Win 95, popout mouse
Fujitsu Lifebook B2154 2000 308x274x40 1400 X X
Win 98
Sharp Zaurus SLC1000 2005 128x87x24 298 X
X Cacko Linux, Dpad
Fujitsu Lifebook U810 2007 150x168x33 712 X X X Win Vista (replaced with OpenSuse),
Toshiba NB100 2009 225x191x33 1000

Win XP (replaced with OpenSuse)
Dell XPS 13 L322X 2013 205x316x18 1360

Ubuntu preloaded (replaced with Kubuntu)
Samsung Galaxy Tab S 8.4 2014 214x142x8
(inc. kbd)
647 X
X Android, Removable Bluetooth Keyboard
GPD Pocket 2017 180x106x18.5 480 X X
Win 10

Sunday, 15 July 2018

Old Soundblaster Live Card and Windows 10

One of my Windows 10 boxes has an old noname soundcard based on the CMedia CMI8738SX which only has Windows 7 driver. When I allowed Windows 10 to auto-upgrade the preceding Windows 7 installation, somehow it kept on working. However, at some point recently the Windows installation became borked to the point that it no longer updated - and no amount of repairing would fix it. There was nothing left but to re-install Windows from scratch (upgrade and repair installs both failed). Fortunately, everything of import is kept on my Nextcloud server so I can resync my data afterwards quite easily.

However, I could not persuade the C-Media card to work nicely with Widnows 10 (it being 64-bit didn't help). I cast around and found that I had a SoundBlaster Live 5.1 PCI card sat in one of my Linux boxes, mainly because it worked with the 3.3V PCI slot in an H8DCL motherboard. However, having worked out previously that C-Media chipsets support 3.3V PCI, and can be converted merely by filing a suitable notch in the PCI connector, I duly did a swap with the Linux box (Linux supports old CMedia shipsets just fine).

The SoundBlaster is such a standard that surely Windows 10 will support it...? Nope. A visit to the Creative site confirms that there is only a W7 driver. Do I sense a conspiracy to sell new kit when the old stuff works fine? Anyway, a search online turns up the KX Project and, more importantly, their GitHub site which ensure things will hang around a bit. Under Windows 10 64-bit the driver installs fine. Ignore the bit about using KXMixer since it does not work, but the W10 mixer seems to work OK for me.

Unfortunately, they are no longer accepting donations - but a big thank you from me.

Tuesday, 10 July 2018

Fun and Games with the SuperMicro X9SRI

Scored a Supermicro X9SRI off eBay as a useful way of using up my DDR3 memory once I start decomissioning some of the older machines in the house. It has 8 slots so I can get a tidy 64GB into it when fully loaded. It turns out that this board - or maybe Intel's server chipsets - are a little tempramental.

I paired it with a Xeon 1650 v2 which is slightly faster than an i7-4930K and is still quite respectable CPU. That's round about a Ryzen 2600 level in modern terms and a lot cheaper, especially when you factor in the price difference between DDR3 and DDR4 RAM. And there my problems started...

I reset the BIOS, loaded up defaults and proceeded to install Linux. Everything went fine, for a while, and then I started getting random hard freezes - but not associated with any particular activity. After swapping out RAM, video cards and everything else I was till no nearer a solution. In desperation, I acquired another Xeon (E5-2609 this time - cheap enough for a quick test) and sure enough, I dropped it in and everything worked fine. So, it's the CPU, I thought, but I was puzzled by the behaviour - working fine under heavy load (Phoronix CPU Benchmark Suite) and the freezing at idle didn't seem like any other failure I'd come across. So I worked my way through the BIOS Options and discovered that the culprit was in the CPU Power Management Settings. If I set it to Power Saving (the default) then I get freezes, but if I set it to Performance then all is well. Interestingly, Linux still seems to do power saving, dropping the clockspeed and voltage of the CPU so it runs quite cool at idle. So I have no idea what the setting does other than break v2 Xeons!

I dropped an old GT 710 card in so I didn't have to live with the 1280x1024 that the on board video can do. I hesitate to call it a GPU but it's only really meant for IPMI redirection so I'm being a little unfair. That works fine with nouveau but I install the proprietary nVidia drivers which have better power management.

Finally, I drop in an Intel Quad Port PRO/1000PT to give me a few more ethernet ports to play with and the board refuses to boot - giving me beep sequences instead. A few more card swaps and it transpires that the Intel card really hates being in PCI-E 3.0 slots and will only start up in the middle, PCI-E 2.0, slot. I was hoping to put it on the slot further away from the video card since the PT gets quite warm but there you are. Reminds me of the old DOS days fiddling around with interrupt combinations to get all your peripherals to work.

Friday, 19 January 2018

Delegating ORCID Tokens

This is the final blog posting arising from the ORCID Delegation workshop held on the 10th October at Jisc in London (with representatives from Oxford, Imperial, Leeds, LSE, ORCID and Jisc). The previous blogs (Delegating ORCID Tokens – background, Revoking ORCID tokens) covered other incidental outcomes, so I will now get to the main topic – the fact that institutional ORCID users needed to explicitly grant access to third party suppliers in addition to their own institution. This behaviour has a number of undesirable side effects (repeating myself somewhat):
  • Communicating this to users can be difficult since they are not always aware of these third parties
  • Getting consistent takeup across multiple systems can be difficult (user loses interest) which makes downstream integration more awkward than necessary
  • Institution has little visibility of these third party interactions – which can cause problems when suppliers are dropped or other issues arise
  • The only way currently round this is to let a supplier use the institutional key – which however then grants them *ALL* the rights can access that the institution has
ORCID uses the OAuth(2) mechanism for authentication and authorization. OAuth already provides the functionality that will allow an institution to generate secondary tokens for third parties and subsequently revoke them:
  • When an ORCID owner authorises institutional access, the institution receives two digital tokens:
    • The access token acts as a “key” that is used to access ORCID data via the ORCID API
    • The refresh token can be used to request additional tokens via the OAuth API
  • There are two primary ways that the refresh token can be used:
    • To request a new access token when it nears expiry, invalidating the current access token – this has been discussed in the previous posting on revocation
    • To request an additional access token which may have reduced permissions and/or differing expiry, which leaves the current access token intact
  • Multiple additional tokens can be requested
  • Additional tokens can be invalidated in a similar way to regular access tokens
Obviously, this additional token mechanism is exactly what is required to allow delegated access to third parties. The issue is that there is no standard mechanism for a third party to know that they should go to an institution to get a token instead of ORCID themselves, nor is there a standard way for an institution to deliver that that token securely. There are several approaches to solving this issue:
  • ORCID keeps track of additional tokens requested and who they are intended for, and issues them when requested.
    • ORCID will need API enhancements to allow institutions to indicate which tokens are for which supplier (and for a supplier to indicate which institution’s token they require)
    • These enhancements are likely to be ORCID specific rather than vanilla OAuth2 so existing code libraries will not exist
    • Institutions will need to implement and use this API, which may involve rather more information release than is desirable
    • Supplier will need to implement and use this API
    • It is unclear how a person with multiple institutional affiliations might be handled without adding significant complexity
    • Short lived tokens would require a three-way interaction between supplier, institution and ORCID – this will be complex and is unlikely to scale effectively
  • Institutions provide an endpoint which the third party always contacts when it needs an access token.
    • This could be implemented as an OAuth2 proxy type of service, which could forward token requests to ORCID on behalf of the institution if an additional token does not already exist, or return an institutional token if the institution in question was not interested in delegation. If developed as a standardised packaged software appliance suitable for running on virtual or cloud infrastructures this could be deployed at an institutional level with minimal effort.
    • Institutions could automatically request and issue short lived tokens relatively easily
    • Institutions retain control over third part interactions
    • Institutions would need a secure (SSL, VPN etc.) network channel to the supplier. This is quite likely to exist already, in practice
  • A third party could maintain a shared proxy-type service for use by multiple organisation
    • This would add another party that needs to be trusted into the interaction, adding effectively a second level of delegation.
    • Cost saving against a locally deployed appliance (as described above) may be minimal when the additional complexity of management is taken into account
Ideally, to make the system robust and workable, ORCID owners should have a verified institutional affiliation (or more than one if necessary) attached to their account so that a third party supplier knows who to contact for a delegation token (either directly or via ORCID). Otherwise, another mechanism would need to be found to indicate which institutions can issue tokens for a particular ORCID owners, which would be somewhat redundant. This relationship would also need to be deasserted promptly when the relationship ends. Any of these approaches will require some investment of effort by both ORCID and member institutions for development and ongoing maintenance. The key questions for the community are thus:
  1. Primarily, whether there is sufficient interest and desire for a solution to the delegation problem for such an investment to be worthwhile
  2. Secondarily, which route is the preferred one. On initial analysis on the day of the workshop, the feeling of the group was that an institutional proxy appliance seemed to be the most attractive option.
As a footnote, Will Simpson of ORCID noted during the meeting that using additional tokens internally for different systems within the institution was also a valid use case in that it allowed ORCID to separate requests from different sources in their logs. This greatly simplifies troubleshooting problems with interactions with multiple institutional systems.

This posting originally appeared on the UK ORCID Consortium blog.

Thursday, 16 November 2017

Retconning this Blog

I've got a load of bits and pieces laying around the internet that I've posted over the years. I'm going to collect them all here with their original dates. I would like to claim it's for preservation but frankly, it just that I can't keep track of the stuff.