dealer mode vs 2pc

[Wangxinqian]

The question
I ran the same program and found that the performance of dealer mode and semi2k is different when running online. I thought they should be the same — dealer mode should only improve efficiency in the offline part, but somehow it also seems faster than the regular semi2k when running online.

[vincent-ehrmanntraut]

Can you provide more information on your program, and maybe create a minimal reproducing example?

My best guess would be that this boils down the "live preprocessing" of MP-SPDZ, i.e., the fact that MP-SPDZ performs the preprocessing on-the-fly when needed. I have, however, never looked at the code of the dealer protocol, so this is just a guess.

[Wangxinqian]

Hi Vincent,

I'm just simply running floatingpoint.Int2FL with dummy input.

[Wangxinqian]

Oh, that live preprocessing thing sounds really cool.

I’ve never heard of it before.

[mkskeller]

Can you be more specific on what you mean by running online? Did you use the -F/--file-preprocessing parameters, or did you observe differences in the output regarding the time taken by the phases? If so, how large is the difference relative to the overall time, and what is the absolute time?

[Wangxinqian]

Adding network round-trip delay on port 13352 for 30ms.

./compile.py -R 64 tutorial
./dealer-ring-party.x 0 tutorial -pn 13352 -h localhost -N 3 -v
./dealer-ring-party.x 1 tutorial -pn 13352 -h localhost -N 3 -v
./dealer-ring-party.x 2 tutorial -pn 13352 -h localhost -N 3 -v

P0 output: Spent 22.3945 seconds (0.055328 MB, 741 rounds) on the online phase and 0.062659 seconds on the preprocessing/offline phase.
P1 output: Spent 22.4549 seconds (0.055312 MB, 740 rounds) on the online phase and 0.002288 seconds on the preprocessing/offline phase.
P2 (dealer) output: Spent 22.2112 seconds on the online phase and 0.002403 seconds (0.216048 MB, 13 rounds) on the preprocessing/offline phase.

./compile.py -R 64 tutorial
./semi2k-party.x 0 tutorial -pn 13352 -h localhost -N 2 -v
./semi2k-party.x 1 tutorial -pn 13352 -h localhost -N 2 -v

P0 output: Spent 49.834 seconds (0.055312 MB, 740 rounds) on the online phase and 6.99442 seconds (3.66813 MB, 115 rounds) on the preprocessing/offline phase.
P1 output: Spent 50.7461 seconds (0.055312 MB, 740 rounds) on the online phase and 6.14264 seconds (3.72035 MB, 102 rounds) on the preprocessing/offline phase.

[mkskeller]

This might be due to the different default choices for the opening. Does it also happen with --direct?

[Wangxinqian]

Does “different default choices for the opening” mean that their online costs for 2PC and (2+1)PC are different?

[mkskeller]

If run without further options yes. The dealer protocol uses --direct by default while Semi2k doesn't. This means that the opening communication happens sequentially in Semi2k whereas it happens in parallel with the dealer protocol, so there are twice as many networking rounds.

[mkskeller]

I've had a look using the delay, but I cannot reproduce the issue with the tutorial computation How did you add the delay? What version or commit did you use? I also noticed that the --direct option is actually used by the dealer protocol, so this cannot be the reason.

[mkskeller]

Another helpful information would be the complete output with --verbose. This would help understand the nature of the communication rounds. As far as I can see, the online rounds are almost the same in both cases, and the delay is clearly the main component of the time spent, so the nature of the rounds would help the analysis.

[Wangxinqian]

I've had a look using the delay, but I cannot reproduce the issue with the tutorial computation How did you add the delay? What version or commit did you use? I also noticed that the --direct option is actually used by the dealer protocol, so this cannot be the reason.

sudo dnctl pipe 1 config delay 50ms
printf 'dummynet in on lo0 proto tcp from any to any port 13352 pipe 1
dummynet out on lo0 proto tcp from any to any port 13352 pipe 1
' | sudo pfctl -f -
sudo pfctl -E

[mkskeller]

Thank you, I managed to reconstruct the issue. However, I observe that the communication pattern is the same in both cases, it's just that the delay varies. I would therefore conclude that this is an artifact of the network infrastructure. This is supported by the fact that introducing a delay on Linux with tc does not produce a difference.