Fast CommunicationWhy Remote Procedure Call?RPC ModelRPC In Modern ComputingGoalsFirefly RPCFast Path in a RPCCaller StubServer StubTransport MechanismSlide 11ThreadingSlide 13Performance EnchancementsPerformance AnalysisTime for 10,000 RPCsSend and Receive LatencySlide 18Stub LatencyFewer ProcessorsSlide 21Future ImprovementsOther ImprovementsRPC Size DistributionFrequency of Remote ActivityTraditional RPCLightweight RPC (LRPC)Overhead AnalysisSources of OverheadImplementation of LRPCBindingCallingStub GenerationMultiple ProcessorsArgument CopyingSlide 36Single-Processor Null() LRPCPerformance ComparisonMultiprocessor SpeedupInter-machine CommunicationCostConclusionFast CommunicationFirefly RPCLightweight RPCCS 614Tuesday March 13, 2001Jeff HoyWhy Remote Procedure Call?Simplify building distributed systems and applicationsLooks like local procedure callTransparent to userBalance between semantics and efficiencyUniversal programming toolSecure inter-process communicationRPC ModelClient ApplicationClient StubClient RuntimeServer ApplicationServer StubServer RuntimeNetworkCallReturnRPC In Modern ComputingCORBA and Internet Inter-ORB Protocol (IIOP)Each CORBA server object exposes a set of methodsDCOM and Object RPCBuilt on top of RPCJava and Java Remote Method Protocol (JRMP)Interface exposes a set of methodsXML-RPC, SOAPRPC over HTTP and XMLGoalsFirefly RPCInter-machine CommunicationMaintain Security and FunctionalitySpeedLightweight RPCIntra-machine CommunicationMaintain Security and FunctionalitySpeedFirefly RPCHardwareDEC Firefly multiprocessor1 to 5 MicroVAX CPUs per nodeConcurrency considerations10 megabit EthernetTakes advantage of 5 CPUsFast Path in a RPCTransport MechanismsIP / UDPDECNet byte streamShared Memory (intra-machine only)Determined at bind timeInside transport procedures “Starter”, “Transporter”, “Ender”, and “Receiver” for the serverCaller StubGets control from calling programCalls “Starter” for packet bufferCopies arguments into the bufferCalls “Transporter” and waits for replyCopies result data onto caller’s result variablesCalls “Ender” and frees result packetServer StubReceives incoming packetCopies data into stack, a new data block, or left in the packetCalls server procedureCopies result into the call packet and transmitTransport Mechanism“Transporter” procedureCompletes RPC headerCalls “Sender” to complete UDP, IP, and Ethernet headers (Ethernet is the chosen means of communication)Invoke Ethernet driver via kernel trap and queue the packetTransport Mechanism“Receiver” procedureServer thread awakens in “Receiver”“Receiver” calls the stub interface included in the received packet, and the interface stub calls the procedure stubReply is similarThreadingClient Application creates RPC threadServer Application creates call thread Threads operate in server application’s address spaceNo need to spawn entire processThreads need to consider locking resourcesThreadingPerformance EnchancementsOver traditional RPCStubs marshal arguments rather than library functions handling argumentsRPC procedures called through procedure variables rather than by lookup tableServer retains call packet for resultsBuffers reside in shared memorySacrifices abstract structurePerformance AnalysisNull() ProcedureNo arguments or return valueMeasures base latency of RPC mechanismMulti-threaded caller and serverTime for 10,000 RPCsBase latency – 2.66msMaxResult latency (1500 bytes) – 6.35msSend and Receive LatencySend and Receive LatencyWith larger packets, transmission time dominatesOverhead becomes less of an issueGood for Firefly RPC, assuming large transmission over networkIs overhead acceptable for intra-machine communication?Stub LatencySignificant overhead for small packetsFewer ProcessorsSeconds for 1,000 Null() callsFewer ProcessorsWhy the slowdown with one processor?Fast path can be followed only in multiprocessor environmentLock conflicts, scheduling problemsWhy little speedup past two processors?Future ImprovementsHardwareFaster network will help larger packetsTriple CPU speed will reduce Null() time by 52% and MaxResult by 36%SoftwareOmit IP and UDP headers for Ethernet datagrams, 2~4% gainRedesign RPC protocol ~ 5% gainBusy thread wait, 10~15% gainWrite more in assembler, 5~10% gainOther ImprovementsFirefly RPC handles intra-machine communication through the same mechanisms as inter-machine communicationFirefly RPC also has very high overhead for small packetsDoes this matter?RPC Size DistributionMajority of RPC transfers under 200 bytesFrequency of Remote ActivityMost calls are to the same machineTraditional RPCMost calls are small messages that take place between domains of the same machineTraditional RPC contains unnecessary overhead, likeSchedulingCopyingAccess validationLightweight RPC (LRPC)Also written for the DEC Firefly systemMechanism for communication between different protection domains on the same systemSignificant performance improvements over traditional RPCOverhead AnalysisTheoretical minimum to invoke Null() across domains: kernal trap + context change to call and a trap + context change to returnTheoretical minimum on Firefly RPC: 109 us.Actual cost: 464usSources of Overhead355us addedStub overheadMessage buffer overheadNot so much in Firefly RPCMessage transfer and flow controlScheduling and abstract threadsContext SwitchImplementation of LRPCSimilar to RPCCall to server is done through kernel trap Kernel validates the callerServers export interfacesClients bind to server interfaces before making a callBindingServers export interfaces through a clerkThe clerk registers the interfaceClients bind to the interface through a call to the kernelServer replies with an entry address and size of its A-stackClient gets a Binding Object from the kernelCallingEach procedure is represented by a stubClient makes a call through the stubManages A-stacksTraps to the kernelKernel switches context to the serverServer returns by its own stubNo verification neededStub GenerationProcedure representationCall stub for clientEntry stub for serverLRPC merges protocol layersStub generator creates run-time stubs in assembly languagePortability sacrificed for Performance Falls back on