SCONE issueshttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues2024-02-28T12:04:43+01:00https://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/50Ability to set destination IP:port for scouting pipelines per subsystem2024-02-28T12:04:43+01:00Dinyar Rabadydinyar.rabady@cern.chAbility to set destination IP:port for scouting pipelines per subsystemHi @rardino,
it just struck me that we won't want a static mapping from DAQ streams to RUs, they should be selected by the FM dynamically. To this end I think it would be good if SCONE provided an interface to set the destination IP:por...Hi @rardino,
it just struck me that we won't want a static mapping from DAQ streams to RUs, they should be selected by the FM dynamically. To this end I think it would be good if SCONE provided an interface to set the destination IP:port in a reasonably elegant way. It's probably not critical right now, but will be important eventually (because I think machines at P5 are given dynamic IPs that can change over time.. ).
I was thinking of an interface approximately like
```python
requests.post('http://localhost:8080/v2/vcu128_ugmtbmtf/0/configure', json={"enabled_system":["ugmt","bmtf"], "l1ds_pipelines": {"ugmt":{"dest_ip": "192.168.1.1", "dest_port":"2000"}, "bmtf":{...}}})
```
What do you think?Rocco ArdinoRocco Ardinohttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/46Add checks for IP and MAC address conflict, Follow-up from "Support for PyHAL...2023-12-20T16:01:46+01:00Petr ZejdlAdd checks for IP and MAC address conflict, Follow-up from "Support for PyHAL-based write/read, adding function execution requests and support for VCU128 tcp/ip-based firmware"We need to add checks for MAC and IP addresses conflicts. The code is in the Dominique's DTH_controller:
https://gitlab.cern.ch/cms_daq_dth/dth_daq_controller/-/blob/master/DTH_control.py?ref_type=heads#L1037
The following discussion...We need to add checks for MAC and IP addresses conflicts. The code is in the Dominique's DTH_controller:
https://gitlab.cern.ch/cms_daq_dth/dth_daq_controller/-/blob/master/DTH_control.py?ref_type=heads#L1037
The following discussion from !37 should be addressed:
- [ ] @pzejdl [commented](https://gitlab.cern.ch/scouting-demonstrator/scone/-/merge_requests/37#note_7403642):
> In general if ARP reply doesn't come then the correct ERROR message is: "Destination host unreachable". This error is fatal, because it is a network problem.
> Concerning the particular line 1206, this is a double check that the MAC address returned by the ARP logic (from the ARP rpely) is valid. If it is zero then we have a "runtime error" or more "firmware error", because that should not happen. Most likely it is a bug in the firmware.
> The error message should be something like: "The MAC address of the destination is invalid!"
> \--
> Something else: The code following the ARP logic is also missing a very important check for the MAC and IP addresses duplicates that needs to be put in place, better soon. Please check the latest DTH controller from Dominique.https://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/44Add monitoring for TCP/IP logic, Follow-up from "Support for PyHAL-based writ...2023-12-20T18:27:08+01:00Petr ZejdlAdd monitoring for TCP/IP logic, Follow-up from "Support for PyHAL-based write/read, adding function execution requests and support for VCU128 tcp/ip-based firmware"We need to add monitoring for registers that hold the internal state of the TCP/IP logic, and if the state changes from expected state it has to find a reason and report it.
TODO(Petr): Add more information here with registers, etc.
Th...We need to add monitoring for registers that hold the internal state of the TCP/IP logic, and if the state changes from expected state it has to find a reason and report it.
TODO(Petr): Add more information here with registers, etc.
The best source is probably the FEROL/FEROL40 controller.
**One example:**
After an attempt to open a connection we need to check for the outcome and if there is a failure, then we need to obtain the reason why it failed. Example is in function `catchTcpError`:
https://gitlab.cern.ch/cmsos/worksuite/-/blob/baseline_sulfur_16/ferol40/src/common/Ferol40.cc#L904
It reads from `eth_10gb_Status_TCP_flags` (on DTH it is called `TCP_100Gb_Status_flags_SND_probe`) and returns the reason why the connection failed.
The function is also called in the monitoring loop to check and diagnose any failure during the TCP data transmission.
--
The following discussion from !37 should be addressed:
- [ ] @dinyar started a [discussion](https://gitlab.cern.ch/scouting-demonstrator/scone/-/merge_requests/37#note_6991564): (+11 comments)
> Same question.https://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/30Clean up code2022-05-04T10:32:17+02:00Dinyar Rabadydinyar.rabady@cern.chClean up codehttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/40Follow-up from "Refactoring of the pyHAL support branch"2023-07-24T21:40:09+02:00Rocco ArdinoFollow-up from "Refactoring of the pyHAL support branch"The following discussion from !39 should be addressed:
- [ ] @rardino started a [discussion](https://gitlab.cern.ch/scouting-demonstrator/scone/-/merge_requests/39#note_6932994):
> A task for me, I need to create a script to creat...The following discussion from !39 should be addressed:
- [ ] @rardino started a [discussion](https://gitlab.cern.ch/scouting-demonstrator/scone/-/merge_requests/39#note_6932994):
> A task for me, I need to create a script to create the hal.so and place it inside SconeHwAccessRocco ArdinoRocco Ardinohttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/42Follow-up from "Refactoring of the pyHAL support branch": check what happens ...2023-11-27T18:41:38+01:00Rocco ArdinoFollow-up from "Refactoring of the pyHAL support branch": check what happens when we reach the timeout in the requestThe following discussion from !39 should be addressed:
- [ ] @rardino started a [discussion](https://gitlab.cern.ch/scouting-demonstrator/scone/-/merge_requests/39#note_6932997):
> When I started to code the new interface, I notic...The following discussion from !39 should be addressed:
- [ ] @rardino started a [discussion](https://gitlab.cern.ch/scouting-demonstrator/scone/-/merge_requests/39#note_6932997):
> When I started to code the new interface, I noticed that when the timeout is reached, the request log goes out of sync. Namely, In the log you get the result of the previous request (or something similar, I need to check to remember). This case can be easily reproduced by trying to run an action that requires few seconds and setting a small timeouthttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/41Follow-up from "Refactoring of the pyHAL support branch": Removing `return_ht...2023-07-25T09:06:36+02:00Rocco ArdinoFollow-up from "Refactoring of the pyHAL support branch": Removing `return_html` flagsThe following discussion from !39 should be addressed:
- [ ] @rardino started a [discussion](https://gitlab.cern.ch/scouting-demonstrator/scone/-/merge_requests/39#note_6932995):
> Do we still want to keep this? I remember it is n...The following discussion from !39 should be addressed:
- [ ] @rardino started a [discussion](https://gitlab.cern.ch/scouting-demonstrator/scone/-/merge_requests/39#note_6932995):
> Do we still want to keep this? I remember it is not used anymorehttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/45Follow-up from "Support for PyHAL-based write/read, adding function execution...2023-12-20T14:53:43+01:00Rocco ArdinoFollow-up from "Support for PyHAL-based write/read, adding function execution requests and support for VCU128 tcp/ip-based firmware"In the CMSSW processing, the streams of data are marked by a "Scouting Source ID" that can be somehow considered a "scouting" FED ID.
SCDAQ adds this source id in the event header, but it would be good if the firmware adds this number in...In the CMSSW processing, the streams of data are marked by a "Scouting Source ID" that can be somehow considered a "scouting" FED ID.
SCDAQ adds this source id in the event header, but it would be good if the firmware adds this number in the packet header.
To do this, we need to add as many registers as the number of streams and SCONE has to write to these registers during "CONFIGURE" (issued by the FM).
---
The following discussion from !37 should be addressed:
- [ ] @dinyar started a [discussion](https://gitlab.cern.ch/scouting-demonstrator/scone/-/merge_requests/37#note_6991562): (+13 comments)
> What do the FED IDs indicate?Dinyar Rabadydinyar.rabady@cern.chRocco ArdinoDinyar Rabadydinyar.rabady@cern.chhttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/43Follow-up from "Support for PyHAL-based write/read, adding function execution...2023-12-20T12:28:32+01:00Rocco ArdinoFollow-up from "Support for PyHAL-based write/read, adding function execution requests and support for VCU128 tcp/ip-based firmware"In the TCP/IP firmware, there are 11 TCP configuration variables whose values have been fine tuned by @pzejdl. These default values are initialized directly in the firmware, with the possibility to change them through a register access.
...In the TCP/IP firmware, there are 11 TCP configuration variables whose values have been fine tuned by @pzejdl. These default values are initialized directly in the firmware, with the possibility to change them through a register access.
However, as stated by Petr, we might need to tweak a bit these values when running in particular conditions.
Thus, SCONE needs to be able to change these values through the REST interface when the function manager requires it (ideally when we configure the board).
The fields for these variables are already in the board configuration json file, but a sub-routine that actually changes this values has to be implemented in the board specific python module (for instance `vcu128.py`) containing the implementation of all the possible actions.
---
The following discussion from !37 should be addressed:
- [ ] @dinyar started a [discussion](https://gitlab.cern.ch/scouting-demonstrator/scone/-/merge_requests/37#note_6991563): (+8 comments)
> Are these supposed to be hardcoded? (i.e. will they almost never change?)Dinyar Rabadydinyar.rabady@cern.chRocco ArdinoDinyar Rabadydinyar.rabady@cern.chhttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/48[future bug] Test suite might fail when we upgrade Flask package2024-01-24T11:19:36+01:00Giovanna Lazzari Miotto[future bug] Test suite might fail when we upgrade Flask packageA potential bug in the test suite might be born when we move to newer versions of Python (e.g., py3.9) and upgrade the package dependencies.
Namely, `Flask` depends on `werkzeug` , which from versions `>= 2.1` (AFAIU) requires an empty ...A potential bug in the test suite might be born when we move to newer versions of Python (e.g., py3.9) and upgrade the package dependencies.
Namely, `Flask` depends on `werkzeug` , which from versions `>= 2.1` (AFAIU) requires an empty JSON data structure to be passed with the `GET` requests of type `Content-Type: application/json`, failing otherwise.
Fix (easy): we need to change all lines of the form `requests.post('`[`http://...:.../`](http://localhost:8080/v2/vcu128_bmtf_tcp/0/reset)`...')` to `requests.post('`[`http://...:.../`](http://localhost:8080/v2/vcu128_bmtf_tcp/0/reset)`...', json={})`
See fix example here: https://gitlab.cern.ch/scouting-demonstrator/scone/-/blob/glazzari/test/PyHAL_support-rhel8build/test.py?ref_type=heads
References:
* [https://github.com/pallets/werkzeug/blob/2.1.0/CHANGES.rst](https://github.com/pallets/werkzeug/blob/2.3.0/CHANGES.rst)
* https://github.com/axios/axios/issues/86
* https://stackoverflow.com/questions/72025772/did-not-attempt-to-load-json-data-because-the-request-content-type-was-not-applGiovanna Lazzari MiottoGiovanna Lazzari Miottohttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/9Refactor code to use exceptions2021-03-03T19:21:24+01:00Dinyar Rabadydinyar.rabady@cern.chRefactor code to use exceptionshttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/49Remove .encode("utf-8") workaround from vcu128 module after moving machines a...2024-01-31T11:19:44+01:00Rocco ArdinoRemove .encode("utf-8") workaround from vcu128 module after moving machines at P5 and test setup to RHEL8This is a workaround needed by the fact that with cc7 machines, the cmsos packages are at version 14, which has only python2 bindings. For scone, we use python 3 and I had to manually build pyhal from cmsos 15 in order to have python3 bi...This is a workaround needed by the fact that with cc7 machines, the cmsos packages are at version 14, which has only python2 bindings. For scone, we use python 3 and I had to manually build pyhal from cmsos 15 in order to have python3 bindings. The built library, though requires to add `.encode("utf-8")` to every register name string when calling read/write.
This will not needed anymore when we will move to RHEL8 all test setup and control machines at P5. In this case, we would have cmsos 15, which has python3 bindingsRocco ArdinoRocco Ardinohttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/34Update README2022-08-25T18:16:15+02:00Thomas Owen JamesUpdate READMEhttps://gitlab.cern.ch/scouting-demonstrator/scone/-/issues/47Wait that the link is up before starting with ARP requests2023-12-22T12:10:53+01:00Rocco ArdinoWait that the link is up before starting with ARP requestsAt the moment, in the CONFIGURE action we also reset the DAQ transceivers and after several other configuration sub-actions, we send the ARP request.
This might result in some ARP requests failures and retries before the check is success...At the moment, in the CONFIGURE action we also reset the DAQ transceivers and after several other configuration sub-actions, we send the ARP request.
This might result in some ARP requests failures and retries before the check is successful, because the link is still down and in the process to come up.
What we should do is the following:
* decouple the DAQ transceivers reset from the CONFIGURE part
* have in firmware a sort of register that tells us when the link is up, so that we can poll it before starting the ARP request
At the moment, what we need to add as temporary workaround is a wait statement before the ARP request, so that we give enough time to the link to come up.Petr ZejdlRocco ArdinoPetr Zejdl