You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More of a comment than an actual issue... But I think this could be of value to those of us who are debugging this library atm.
I wanted to confirm my suspicion as to what was causing the difference in performance when running glados against fluffy / trin. For context, running glados against fluffy resulted in drastically improved performance when compared to running glados against trin. It appeared as though fluffy was having no trouble with utp transfers, while trin was struggling. Since trin-bridge is the only bridge running, the conclusion was that utp txs for trin -> fluffy were working just fine, whereas trin -> trin was broken (for bodies & receipts ... aka any significantly long utp tx).
Results from running trin-bridge in backfill mode for 15mins. trin-bridge is run in isolation against a single client. Each utp tx is logged and marked as success & failure.
trin-bridge -> trin
trin-bridge -> fluffy
For whatever reason, it appears as though trin -> fluffy utp txs work flawlessly. Whereas trin -> trin utp txs are problematic. Hopefully this can help shed some insight as to where the bugs might reside.
The text was updated successfully, but these errors were encountered:
More of a comment than an actual issue... But I think this could be of value to those of us who are debugging this library atm.
I wanted to confirm my suspicion as to what was causing the difference in performance when running glados against fluffy / trin. For context, running glados against fluffy resulted in drastically improved performance when compared to running glados against trin. It appeared as though fluffy was having no trouble with utp transfers, while trin was struggling. Since
trin-bridge
is the only bridge running, the conclusion was that utp txs fortrin
->fluffy
were working just fine, whereastrin
->trin
was broken (for bodies & receipts ... aka any significantly long utp tx).Results from running
trin-bridge
in backfill mode for 15mins.trin-bridge
is run in isolation against a single client. Each utp tx is logged and marked as success & failure.trin-bridge -> trin
trin-bridge -> fluffy
For whatever reason, it appears as though
trin
->fluffy
utp txs work flawlessly. Whereastrin
->trin
utp txs are problematic. Hopefully this can help shed some insight as to where the bugs might reside.The text was updated successfully, but these errors were encountered: