Not only the scheduling delay after the timer pulse will vary in an unpredictable way and amount, you also will loose some of the 1 mSec calls. If this does not matter, as it will not happen too often, it should be possible to set HZ to 1000.
With Kernel 2.4 this HZ is used as well for Kernel modules as for application. There are some Kernel modules and many applications that implicitly assume HZ=100 and don't use the #define constant. Those might fail in an unpredictable way.
With Kernel 2.6, HZ for applications always is 100, (of course you _can_ change even this in the Kernels source) so applications are not affected. Kernel modules are compile with a different setting of HZ (the running Kernel takes care of converting between the HZ settings appropriately).
Thus with 2.6 you can set HZ for drivers and for applications independently. While changing the User HZ value is not recommended, the Kernel HZ value is different with different architectures. Default is
100 for ARM, 1000 for X64 and (I think) either of 100 or 1000 with different PPCs.
Kernel 2.6 will show a much better soft realtime behavior than 2.4.
Hope this helps,
-Michael