Is the nds.gwosc.org server down?

Data Analysis
43

@yoel Thank you for the question. I just rant this test and it seems OK.

Python 3.13.7 | packaged by conda-forge | (main, Sep  3 2025, 14:24:46) \[Clang 19.1.7 \] on darwin

Type "help", "copyright", "credits" or "license" for more information.

>>> from gwpy.timeseries import TimeSeries

>>> data = TimeSeries.fetch('L1:CAL-PCALX_RX_PD_OUT_DQ', start=1368980000, end=1368980010, host\\

='nds.gwosc.org')



>>> data

<TimeSeries(\[1.0455619e-11, 1.1145266e-11, 1.0765115e-11, ...,

             1.1138348e-11, 1.0819855e-11, 1.0106696e-11\],

            unit=Unit("ct"),

            t0=<Quantity 1.36898e+09 s>,

            dt=<Quantity 6.10351562e-05 s>,

            name='L1:CAL-PCALX_RX_PD_OUT_DQ',

            channel=<Channel("L1:CAL-PCALX_RX_PD_OUT_DQ" \[reduced\], 16384.0 Hz) at 0x1517d8550>)>
44

I hit a related but not identical issue — TimeoutError (socket read timeout)
on repeated TimeSeries.fetch_open_data() calls against the public GWOSC
REST API (not the NDS/AUX-channel path you’re using here), while running
a long batch of injection-recovery trials that each fetched a fresh
segment over the network.

Different endpoint/protocol from your NDS error, so this probably won’t
directly diagnose your AUX-channel problem — but as a data point: GWOSC-
adjacent infrastructure reliability issues do seem to be a recurring,
intermittent pattern, not obviously tied to one ISP/laptop/time-segment
combination, consistent with what you’re describing.

For anyone hitting this on the public strain side specifically: the
practical workaround that worked for me was to download the relevant
GWOSC HDF5 file(s) once, then read segments locally (h5py) instead of
calling fetch_open_data() per trial — eliminated the timeouts entirely
for my use case, though obviously doesn’t help if you specifically need
live/proprietary AUX channel access via NDS.