Tune PLIP Timing Safely with plipconfig
PLIP links are slow by nature, and plipconfig is the one tool that lets you shave microseconds off the timing without touching a config file. You will inspect a PLIP interface, change its runtime nibble or trigger wait, and verify the result rather than guess whether the hardware actually supports the request. Allow about fifteen minutes for a live link, including a small test transfer. The examples use plipconfig from Ubuntu's net-tools package, version 2.10-0.1ubuntu4.4, with the upstream program itself reporting version 2.10.
The route
Jump straight to the step you need, or tick off Done means at the end.
PLIP is the old parallel-port IP driver. You need an already configured PLIP interface at both ends of the link, a cable that already works, and an account able to manage the network device. Reading status is normally unprivileged; changing the driver settings may need root or the relevant network administration privilege.
1. Confirm the installed command
Check the binary and its package before changing anything. These are read-only:
$ command -v plipconfig
/usr/sbin/plipconfig
$ dpkg-query -W -f='${Package} ${Version}\n' net-tools
net-tools 2.10-0.1ubuntu4.4
$ plipconfig --version
net-tools 2.10
John Paul Morrison, Alan Cox et al.
The command takes one interface name, followed by the optional words nibble and trigger. Do not assume a modern Ethernet interface will do; use the exact PLIP interface name already configured on this host, something like plip0 or plip1.
2. Read the current timing
Replace PLIP_INTERFACE with the real interface name. Supplying only that name asks the driver for its current values and changes nothing:
$ plipconfig PLIP_INTERFACE
PLIP_INTERFACE nibble CURRENT_NIBBLE trigger CURRENT_TRIGGER
The actual numbers come from the driver, so the line above is a shape to expect, not something to copy literally. Record both values: the documented defaults are 3000 microseconds for nibble and 500 microseconds for trigger, but whatever the device reports right now is your real baseline.
Checkpoint
If this reports ioctl: Operation not supported, the named interface simply will not accept PLIP's private driver request on this machine; stop here. If it reports ioctl: No such device, fix the interface name or configure the device before you try tuning anything.
3. Choose one small timing change
The manual says lowering the waits can sometimes help speed, but it also warns about higher CPU use, worse interrupt response, dropped serial characters and lost PLIP packets. Make one modest change at a time, and never copy an aggressive value from another machine: parallel-port hardware, cable length and CPU speed all shift the result.
For example, if the status command reported nibble 3000 and trigger 500, try a conservative trial by changing only the nibble wait:
$ sudo plipconfig PLIP_INTERFACE nibble 2500
PLIP_INTERFACE nibble 2500 trigger 500
Both timing values are in microseconds. The command reads the current settings first, then submits the requested values. Treat that displayed line as confirmation of what the utility read back, not as proof a packet transfer is actually healthy.
This is a live kernel setting, not a permanent configuration file, and it can disrupt an active PLIP transfer. Warn anyone using the link before applying it, and never run it during a transfer that matters.
4. Verify the setting and the link
Read the interface again, without sudo unless your system requires it:
$ plipconfig PLIP_INTERFACE
PLIP_INTERFACE nibble 2500 trigger 500
Then run the same small, repeatable transfer or connectivity test you used before the change. Compare packet loss, transfer time and CPU use: a faster result with dropped packets is a failed tuning attempt, not a win. If the other end of the link is reachable, make the same change there too, only after recording its own baseline, and test both directions.
plipconfig itself has nothing that measures throughput, so use a separate transfer or network test and keep the method consistent. If the link stops responding, check the PLIP interrupt assignment and interface configuration with your normal network tools. The manual specifically points to a wrong IRQ as a more likely cause than timing that is too aggressive; do not go changing the IRQ just because a timing experiment failed.
5. Restore the recorded values
To undo the trial, submit the values you recorded in step 2:
$ sudo plipconfig PLIP_INTERFACE nibble ORIGINAL_NIBBLE trigger ORIGINAL_TRIGGER
PLIP_INTERFACE nibble ORIGINAL_NIBBLE trigger ORIGINAL_TRIGGER
$ plipconfig PLIP_INTERFACE
Replace both placeholders with actual numbers, not the words shown. Recheck the link once you have restored them. A reboot or interface reinitialisation may also discard runtime settings, but do not rely on that as your recovery plan while a working link is actually needed. The command never touches a persistent network configuration, so any permanent setting has to be managed separately through your distribution's network tools.
Common traps
- Using an Ethernet device name produces an unsupported ioctl rather than useful PLIP status.
- Changing both values at once makes it hard to tell which change actually caused packet loss or CPU pressure.
- Lower numbers are not automatically better. Long parallel cables are especially unsuitable, and the manual warns the port was never designed for long cable runs.
- A successful command is not an end-to-end test. Check the link in both directions and watch for serial devices losing characters.
- Do not put
PLIP_INTERFACE,ORIGINAL_NIBBLEorORIGINAL_TRIGGERliterally in a production command.
Done means
- The installed net-tools version and PLIP interface were identified.
- The original nibble and trigger values were recorded before any change.
- Only one modest timing change was tested at a time.
- Status was read back and an end-to-end transfer was checked.
- The recorded values can restore the previous runtime state if the trial is worse.